Respuesta y cierre de ticket

1. Objetivo

Establecer cómo se redacta, entrega y registra la respuesta al socio y cómo se cierra formalmente el ticket, dejando constancia de la resolución y garantizando que el socio pueda verificar el cierre a través del enlace de consulta.

2. Alcance

Cubre la etapa de respuesta y cierre: redacción de la respuesta, transición de estado a resolved, entrega al socio, posible reapertura si la resolución no es satisfactoria, y cierre definitivo.

No cubre:

• la apertura del ticket → [[wiki/entities/dispensai/protocolos/CAL-002]];
• la autoapertura → [[wiki/entities/dispensai/protocolos/CAL-003]];
• la investigación → [[wiki/entities/dispensai/protocolos/CAL-004]];
• la derivación a no conformidad → CAL-006.

3. Definiciones

• Respuesta: mensaje visible para el socio que explica qué se encontró, qué se actuó y cuál es la resolución.
• Cierre: transición del ticket a estado closed, estado terminal sin posibilidad de reapertura por el sistema.
• Reapertura: vuelta de resolved a in_progress, habilitada por el workflow cuando la resolución no es satisfactoria.
• Nota interna: mensaje visible sólo para el equipo de la organización; no sale al socio.
• Cierre por duplicidad: cierre de un ticket idéntico a otro ya gestionado, dejando constancia del folio original.

4. Roles y responsables

Rol	Responsabilidad
Responsable de Soporte / Calidad	Redacta la respuesta y ejecuta el cierre.
Sistema	Valida las transiciones, registra el historial y entrega la respuesta al socio en su enlace de consulta.
Socio	Puede ver la respuesta desde su enlace de consulta y solicitar reapertura si no está conforme.
Calidad	Verifica que los tickets cerrados tengan respuesta documentada.

5. Disparador de inicio

La queja alcanza el estado in_progress tras la investigación de CAL-004. El responsable tiene los antecedentes suficientes para redactar la respuesta.

6. Requisitos previos

• El ticket está en estado in_progress con investigación concluida.
• El responsable puede registrar mensajes en el ticket.
• El socio tiene un enlace de consulta activo (access_id) para recibir la respuesta.

7. Entradas

• Resultado de la investigación (notas internas del responsable).
• Antecedentes revisados (descripción, dispensación, evaluación de origen, si aplica).
• Decisión de resolución: atendida, rechazada, derivada a NC, cerrada por duplicidad.

8. Procedimiento paso a paso

1. El responsable redacta la respuesta en el ticket como un mensaje visible para el socio, que explica qué se encontró y qué resolvió.
2. El responsable avanza el estado a resolved. El sistema valida la transición in_progress → resolved. El registro del historial con usuario, fecha y motivo no se produce hoy: la tabla destino no existe (ver brecha 5 en §17). El estado sí queda en service_complaints.
3. La respuesta queda visible para el socio en su enlace de consulta (/tickets/[accessId]), sin que el socio requiera iniciar sesión.
4. Si el socio no queda conforme, el responsable puede volver el ticket a in_progress (transición resolved → in_progress habilitada por el workflow) para continuar la gestión.
5. Cuando la resolución es definitiva, el responsable avanza a closed. El sistema valida la transición resolved → closed; el registro del historial tampoco se produce (brecha 5).
6. El estado closed es terminal: el sistema no permite transición alguna desde closed.

9. Puntos de control

#	Control	Momento
C1	Mensaje de respuesta redactado y marcado como visible para el socio	Paso 1
C2	Transición resolved válida — la validación opera; el registro en historial no (brecha 5)	Paso 2
C3	Respuesta accesible por el socio en su enlace de consulta	Paso 3
C4	Reapertura posible si la resolución no es satisfactoria	Paso 4
C5	Transición closed válida — sin registro en historial (brecha 5)	Paso 5
C6	Estado closed es terminal — sin posibilidad de nueva transición	Paso 6

10. Criterios de decisión

Situación	Resultado
Investigación concluida y respuesta redactada	Avanzar a resolved y notificar al socio
Socio no conforme con la respuesta	Volver a in_progress para continuar gestión
Ticket duplicado de otro ya gestionado	Cerrar con constancia del folio original
Queja revela causa raíz sistémica	Iniciar derivación paralela en CAL-006 antes de cerrar
Queja resuelta y socio sin nuevas observaciones	Avanzar a closed

11. Excepciones y escalamiento

• Cierre por duplicidad. No se borra el ticket; se cierra en closed con nota interna que referencia el folio del ticket original.
• Queja anónima. La respuesta se publica en el enlace de consulta. No es posible comunicarla por otro canal porque no existe identidad del presentador.
• NC asociada abierta. Si la queja generó una NC automática (CAL-004), el cierre de la queja no cierra automáticamente la NC. El responsable de Calidad la gestiona por separado en el flujo de no conformidades.
• Ticket en closed con NC abierta. Es un estado válido. La NC registra la causa raíz sistémica; la queja registra la atención al caso individual. Son cadenas de evidencia distintas.

12. Registros generados

• Mensaje visible al socio con la respuesta y la resolución, en complaint_messages.
• Estado final del ticket en service_complaints.

No se genera hoy, porque su tabla destino no existe (brecha 5 en §17): el registro de las transiciones in_progress → resolved y resolved → closed con usuario y motivo, y el historial consultable vía getWorkflowHistory. El estado final del ticket queda; quién lo cerró y cuándo, no. La constancia de esos datos es hoy humana.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Tickets cerrados con respuesta	Tickets en closed con mensaje visible ÷ total cerrados	100 %	service_complaints + complaint_messages
Tiempo en resolved	Promedio de días entre resolved y closed	< 5 días	No calculable hoy — sin historial de transiciones (brecha 5)
Tickets reabiertos	Tickets que volvieron de resolved a in_progress ÷ total	Monitoreo de tendencia	No calculable hoy — sin historial de transiciones (brecha 5)
Tickets duplicados cerrados	Conteo de cierres por duplicidad	Seguimiento; si sube, revisar CAL-002	service_complaints

14. Riesgos y controles

Riesgo	Control	Tipo
Cierre sin respuesta al socio	Ver brecha 1 en §17	—
Cierre prematuro antes de investigar	Workflow obliga paso por in_progress antes de resolved	Preventivo
NC asociada olvidada	Regla del §11 — gestión separada documentada	Manual
Respuesta no visible para el socio	C3 — verificar visible_to_user en complaint_messages	Preventivo
Reapertura sin justificación	Sin control efectivo — el motivo de la transición no se persiste	Brecha (§17, brecha 5)

15. Normativa y referencias

• ISO 9001:2015 §10.2, No conformidad y acción correctiva: el cierre de una queja requiere registro de lo actuado y de la resolución adoptada.
• ISO 9001:2015 §10.3, Mejora continua: el análisis de quejas cerradas alimenta la mejora del servicio.
• ISO 26000:2010 §6.7.6, Resolución de conflictos y reclamos: la respuesta al reclamante es parte del proceso justo.
• [[wiki/entities/dispensai/protocolos/CAL-002]] — apertura del ticket.
• [[wiki/entities/dispensai/protocolos/CAL-004]] — investigación previa al cierre.
• CAL-006 — derivación a no conformidad cuando el cierre revela causa raíz sistémica.

16. Anexos y formularios vinculados

• Plantilla de respuesta a queja (texto base).
• Modelo de notificación de cierre.

17. Implementación en el sistema

El protocolo está implementado en su estructura de workflow. El sistema garantiza el orden de las transiciones; su registro histórico no se persiste hoy (brecha 5). La obligatoriedad de la respuesta antes del cierre no está enforced por el código: es una responsabilidad operativa del equipo de Soporte y Calidad.

Elemento del protocolo	Dónde vive
Paso 2 — transición resolved	updateComplaintWorkflowStatus("queja", complaintId, "resolved", userId, reason) en dispensai/lib/iso-workflows.ts
Paso 5 — transición closed	updateComplaintWorkflowStatus("queja", complaintId, "closed", userId, reason)
Registro de historial	logWorkflowTransition escribe a iso_workflows — tabla inexistente (brecha 5)
Estado terminal closed	WORKFLOW_TRANSITIONS.queja.closed = [] — sin transición posible
Reapertura habilitada	WORKFLOW_TRANSITIONS.queja.resolved = ["closed", "in_progress"]
Mensajes visibles al socio	Tabla complaint_messages con columna visible_to_user; consultables en /tickets/[accessId] sin sesión
Historial consultable	getWorkflowHistory("queja", complaintId) — sin filas que devolver (brecha 5)

Brechas conocidas:

1. El cierre no exige respuesta documentada. updateComplaintWorkflowStatus valida la transición tipológica pero no verifica que exista al menos un mensaje visible al socio. Un responsable puede pasar el ticket a resolved y luego a closed sin haber redactado ninguna respuesta. El riesgo principal del protocolo —cierre prematuro— puede ocurrir en el sistema.
2. Sin confirmación de satisfacción del socio. El sistema no solicita ni registra si quien presentó la queja considera su caso resuelto. La transición a closed es unilateral del responsable.
3. NC asociada sin vínculo de cierre. La no conformidad creada automáticamente en CAL-004 (queja crítica > 3 días) no se cierra al cerrar la queja. No hay campo en service_complaints ni en service_non_conformities que registre el vínculo bidireccional. El cierre de ambas cadenas requiere gestión manual separada, sin alerta de pendiente.
4. La transición a resolved/closed no notifica al socio. La inspección de app/actions/iso.ts no encontró llamada a notificación en el camino de updateComplaintWorkflowStatus. El socio puede enterarse del cierre solo si consulta proactivamente su enlace en /tickets/[accessId].
5. La tabla iso_workflows no existe, y el plano ISO está apagado. Este protocolo la declaraba como registro de evidencia del cierre. Fue eliminada por dispensai/supabase/migrations/20260515000000_iso_standby.sql:128 (DROP TABLE IF EXISTS public.iso_workflows CASCADE) y vuelve a eliminarse en 20260629000000_cross_tenant_dispensation_fix_canonical.sql:83. Ninguna migración posterior la recrea: su única sentencia CREATE TABLE vive en 20240101000000_baseline_schema.sql, anterior al drop. El plano ISO se trasladó al Worker dispensai/backends/workers/iso (D1), detrás de la bandera ISO_ENABLED, en false en los seis tenants con .env local; con la bandera apagada logISOSystemEvent es un no-op silencioso (dispensai/lib/iso-event-logger.ts:8). Consecuencia operativa: el cierre del ticket ocurre y su estado final queda en service_complaints, pero quién cerró, cuándo y con qué motivo no deja rastro verificable en el sistema. La cadena de evidencia del cierre depende de los mensajes en complaint_messages y de constancia humana. Esto también agrava la brecha 3: el vínculo con la no conformidad no sólo carece de campo, sino que service_non_conformities tampoco existe (20260515000000_iso_standby.sql:138).

Brecha observada en auditoría 2026-08-31

• Ruta no encontrada exacta: /admin/farmiemos/rse/quejas/[id] — puede ser variante (singular/plural, /admin vs /dashboard) o ruta renombrada. Acción correctora: actualizar el frontmatter con la ruta real que usa el sistema.
• Ruta no encontrada exacta: /tickets/[accessId] — puede ser variante (singular/plural, /admin vs /dashboard) o ruta renombrada. Acción correctora: actualizar el frontmatter con la ruta real que usa el sistema.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial, derivada de la navegación del flujo de quejas y del módulo de workflows	Calidad
1.1	2026-08-29	Cierre de INFERIDO: brecha 4 confirmada — app/actions/iso.ts no contiene llamada de notificación en updateComplaintWorkflowStatus; ausencia es brecha confirmada. Estado ascendido a Vigente.	Harness dispensai-protocolos
1.2	2026-08-29	Corrección de evidencia inexistente: iso_workflows sale del frontmatter (registro_evidencia, implementacion.tablas). Nueva brecha 5 con las migraciones que la eliminaron y el estado de ISO_ENABLED. §8, §9, §12, §13, §14 y §17 corregidos para no afirmar un registro que no ocurre. Brechas 4 → 5.	Sistema / admin
1.0+audit-2026-08-31	2026-08-31	Detectados gaps en auditoría: /admin/farmiemos/rse/quejas/[id], /tickets/[accessId]. §17 actualizada para documentar la brecha con evidencia de código. Estado documental sin cambio.	Auditoría automática