Retainer de soporte: paquete tickets recurrentes crónicos (con IA)

Cuando un cliente con retainer de soporte vuelve a abrir el mismo ticket—el login falla tras cada parche, un informe “se queda en blanco”, una integración cae cada lunes—no tienes tres bugs distintos. Tienes un problema crónico que se comerá las horas del retainer si no lo nombras, lo cuentas y lo llevas a un arreglo permanente.

Este playbook es para autónomos y agencias pequeñas que ya hacen la revisión mensual del retainer y saben cerrar una retrospectiva post-incidente. No es un incidente urgente P1 ni un RCA puntual tras estabilizar. Es el camino intermedio: tickets duplicados con el servicio operativo, con actualizaciones escritas al cliente y un umbral claro para pasar de break/fix a gestión de problemas o a una solicitud de cambio.

Cuándo usar este paquete

Úsalo cuando todas estas condiciones se cumplan:

• El retainer está activo y los tickets entran en tu SLA facturable.
• Dos o más tickets en 30 días comparten la misma clase de síntoma (mismo error, mismo paso, misma integración).
• Cada reapertura se “arregló” con un workaround, pero no cambió config, código ni responsable.
• El cliente está cansado de que “vuelva a pasar” y pide claridad, no otro parche en silencio.

Si el sistema está caído para todos, usa primero tu paquete de incidente urgente. Si piden trabajo nuevo fuera de soporte, deriva con tu pack de fuera de alcance.

Qué vas a entregar

1. Un Registro de Problema en Google Docs (una página): log de ocurrencias, impacto, causa probable, responsable, fecha objetivo de fix.
2. Un memo ChatGPT separando HECHO vs SUPOSICIÓN sobre si son duplicados reales o regresiones.
3. Una secuencia de tres emails en Gmail: reconocer el patrón, compartir el registro, comprometer la siguiente puerta de decisión.
4. Una fila en la revisión mensual con el ID del problema para renovaciones y política de horas no usadas.

Paso 1 — Etiquetar duplicados sin discutir

Exporta o copia los últimos tres tickets relacionados (IDs, fechas, síntoma en una línea, qué hiciste). Pega en ChatGPT:

Eres mi lead de soporte. Abajo hay extractos de tickets del mismo retainer.
Entrega: (1) HECHOS — fechas, texto de error, entornos; (2) SUPOSICIONES — lo no demostrado; (3) PUNTUACIÓN DUPLICADO 0–5; (4) TRES PREGUNTAS al cliente antes del siguiente intento.
No inventes líneas de log.

Guarda la salida al inicio del Registro de Problema. Si dominan las SUPOSICIONES, la siguiente hora facturable es recoger evidencia, no otro tweak.

Paso 2 — Crear el Registro de Problema (Google Docs)

Plantilla:

Campo	Ejemplo
ID problema	PR-2026-014
Clase de síntoma	“Fallo SSO tras actualizar plugin del vendor”
Primera vez	2026-09-12
Ocurrencias (30d)	3 tickets (#118, #124, #131)
Impacto	~12 usuarios bloqueados 15–40 min
Workarounds	Limpiar caché, rollback plugin v2.1
Causa probable	Orden de hooks + dominio de cookie
Responsable	Tú + contacto IT del cliente
Fecha objetivo fix	2026-11-08
Escalado	4.ª ocurrencia → solicitud de cambio

El doc es la fuente única de verdad cuando el helpdesk parte hilos.

Paso 3 — Umbral de ocurrencias

Elige el umbral antes de la tensión:

• 2 en 30 días → abrir Registro de Problema; avisar al cliente por escrito.
• 3 → dejar de tratar tickets como independientes; convocar decisión (call 20 min o async).
• 4 → camino automático a solicitud de cambio o mini proyecto; el retainer cubre diagnóstico, no rework infinito.

Si no puedes cambiar el SOW, declara el umbral en el Email #1.

Paso 4 — Secuencia Gmail (lista para pegar)

Email 1 — Reconocer el patrón

Asunto: [Retainer] Seguimiento incidencia recurrente — PR-2026-014

• Hemos visto este síntoma en #118 y #124; abro Registro de Problema para atacar la causa.
• Sin aprobación extra aún; próxima actualización el [fecha].
• Enlace al Google Doc.

Email 2 — Registro + decisión (3.ª ocurrencia o causa creíble)

Asunto: [Retainer] Registro de problema + fix propuesto — PR-2026-014

Tabla de ocurrencias, causa probable, opciones A) fix en horas del retainer esta semana, B) solicitud de cambio con estimación. Pedir respuesta A o B.

Email 3 — Cierre

Asunto: [Retainer] Incidencia recurrente resuelta — PR-2026-014

Pasos de verificación, enlace al doc final, qué vigilar el próximo mes. Una línea en el log de revisión mensual.

Misma disciplina que tu pack de incumplimiento SLA: decisiones por escrito.

Paso 5 — Verificación antes de cerrar

• Reproducir el síntoma una vez en staging o ventana segura.
• Documentar versión vendor o cambio de config en el Registro.
• Pedir al contacto que responda “verificado” en el Email #3.

Si falla, incrementa ocurrencias y vuelve al Paso 2; no borres historial.

Paso 6 — Alimentar la revisión mensual

En tu revisión mensual de retainer:

Tema	Problemas abiertos	Cerrados este mes	Horas en crónicos
Tickets recurrentes	PR-2026-014	1	4,5 h

Protege cuando pregunten por horas sin “features nuevas”.

Errores habituales

• Tratar cada reapertura como ticket nuevo.
• Omitir emails escritos al cliente.
• Fix permanente sin aprobación → disputas; usa solicitud de cambio si es build.
• Confundir con RCA post-incidente (evento único ya cerrado).

Notas de herramientas

ChatGPT ordena ruido; tú validas. Google Docs comparte con aprobadores no técnicos. Gmail deja audit trail, como en tu pack degradación P2.

Checklist rápido

• Clase de síntoma duplicada en ≥2 tickets / 30 días
• Snapshot HECHO/SUPOSICIÓN en el Registro
• Umbral comunicado al cliente
• Secuencia de tres emails enviada
• Evidencia de verificación antes del cierre
• Revisión mensual actualizada

Los tickets crónicos aburren hasta que dominan el mes. Este pack los hace visibles, contados y finitos—lo que un buen retainer debe sentir.