Ir al contenido principal

Ciclo de vida de la orden de servicio

Cómo avanza una orden de servicio de Draft a Open, In Progress y Closed — quién actúa en cada etapa y qué registra la traza de auditoría.

Técnico de servicio
Administrador

Una Service Order es el registro autoritativo de reparo atado a un Support Ticket. Los clientes ven progreso de alto nivel en el ticket; tu taller ve status granulares dentro de la orden. Esta página explica el ciclo de vida simplificado (DraftOpenIn ProgressClosed) y cómo mapea los status detallados en la UI.

Diagrama del ciclo de vida (conceptual)

Draft ──► Open ──► In Progress ──► Closed
              │         │
              │         ├── Diagnosing
              │         ├── Waiting Parts
              │         └── Awaiting Approval
              └── Cancelled (terminal)

Draft es opcional — algunos concesionarios crean órdenes directamente en Open desde un ticket. Cancelled es una rama terminal cuando el trabajo se detiene antes de completarse.

Draft

ActorAcciones
Support / AdminCrear orden desde el ticket; vincular Support Ticket y ERP Quote ID
TechnicianRaro — se usa cuando la intake está agendada pero el hardware aún no llegó

La traza de auditoría registra usuario y timestamp de creación.

Open

ActorAcciones
TechnicianAplicar template de checklist Receiving; capturar fotos
SupportConfirmar contacto del cliente en el ticket vinculado

Open significa que el trabajo fue aceptado pero el diagnóstico no terminó. Los subestados del portal suelen mostrar Diagnosing después de guardar Diagnosis verdict — tratá Diagnosing como trabajo tardío de Open, aún no In Progress.

Eventos de auditoría: checklist aplicado, ítem verificado, Receiving checklist completed.

In Progress

ActorAcciones
TechnicianActualizar checklist
Customer (vía portal)Firmar Customer Approval para trabajo billable

In Progress cubre todo el trabajo activo de reparo. Subestados comunes:

  • Waiting Parts — orden en espera; no se está trabajando activamente.
  • Awaiting ApprovalAuthorization está Pending; líneas billable bloqueadas.
  • In Progress (estrecho) — tiempo de llave.

Las transiciones deben seguir el estado real del taller — saltar a Completed sin checklist Release rompe la defensibilidad de la garantía.

Closed

ActorAcciones
TechnicianChecklist Release, Customer Signature, status Completed
SupportTicket ResolvedClosed, prompt de CSAT

Closed mapea al status Completed en la UI (o Cancelled cuando se aborta). La traza de auditoría retiene:

  • Cada cambio de status con usuario y hora
  • Verificaciones de checklist (Verified by {name})
  • Ids de lote Warranty Claim vinculados

Revisores OEM y financieros leen esta traza durante inspección de garantía.

Quién puede transicionar

TransiciónRol típico
Crear Draft/OpenSupport, Technician, Admin
Guardar Diagnosis verdictTechnician
Solicitar Customer ApprovalTechnician o Support
Marcar CompletedTechnician
CancelledAdmin o Technician senior con motivo documentado

Traza de auditoría

La línea de tiempo del ticket refleja hitos de la orden de servicio: orden creada, fases de checklist, firma capturada, lote de garantía vinculado. En disputas, exportá o capturá pantalla de la pestaña Overview y del historial Checklist — los timestamps en ítems Photo required son especialmente persuasivos.

Relacionado

¿Te resultó útil esta página?

Editar esta página en GitHub

Última actualización: 20 de oct de 2018