Paquete de degradación de rendimiento (P2) en retainer de soporte (con IA)

Tu cliente con retainer dice que la aplicación "va lenta" pero el login responde. No es el playbook de incidente urgente P1 ni una ventana de mantenimiento planificada. Es degradación de rendimiento (P2): impacto parcial, alcance difuso y mucho riesgo de optimización infinita si no documentas la línea base y biseccionas el problema por escrito.

Este paquete ofrece a autónomos y agencias pequeñas una respuesta repetible mientras el retainer sigue siendo facturable y defendible.

Cuándo usar este paquete (y cuándo no)

Úsalo cuando:

• Las funciones principales funcionan pero la latencia, los timeouts o la cola empeoran respecto a la línea base.
• Los usuarios pueden trabajar, aunque con fricción.
• Necesitas un plan escrito antes de invertir otra hora en suposiciones.

No lo uses cuando:

• El servicio está caído para la mayoría → pasa al paquete de incidente urgente P1.
• Ya conoces la causa y ejecutas un cambio planificado → usa tu brief de mantenimiento.
• La petición es desarrollo nuevo → deriva a solicitud de cambio o fuera de alcance.

Qué vas a entregar

1. Instantánea HECHO / SUPOSICIÓN con ChatGPT (tú verificas cada hecho).
2. Brief de degradación de rendimiento de una página en Google Docs (línea base, alcance, plan de bisección, disparadores de escalado).
3. Cadencia de tres correos en Gmail (acuse → punto medio → resuelto o escalado).
4. Fila en la revisión mensual para que la lentitud recurrente no parezca doce misterios sueltos.

Más playbooks en guías.

Flujo de extremo a extremo

Paso 1 — Triaje con ChatGPT (HECHO vs SUPOSICIÓN)

Pega el mensaje del cliente y describe capturas (sin secretos). Prompt de ejemplo:

Eres mi asistente de triaje de soporte. Separa HECHO (citado o medido) de SUPOSICIÓN (suposiciones). Lista datos que faltan para un brief de rendimiento: URLs afectadas, usuarios, hora de inicio, códigos de error, cambios recientes, región de hosting. Propón tres comprobaciones de bisección ordenadas de más baratas a más caras. No inventes métricas.

Regla humana: si ChatGPT marca HECHO algo que el cliente solo dijo "va lento", baja a SUPOSICIÓN hasta medir.

Paso 2 — Brief de degradación (Google Doc)

Crea un documento con este esquema:

Sección	Contenido
Severidad	P2 — degradado, no caído
Impacto	Quién, cuántos, qué flujos
Línea base	Latencia o error rate bueno conocido (enlace a monitorización si existe)
Señal actual	Marcas de tiempo, HAR de muestra, captura de cola
Cambios recientes	Despliegues, DNS, SSL, plugin, edición del cliente
Plan de bisección	Comprobaciones ordenadas (red local → DNS → app → BD → tercero)
Time box	Horas facturables máximas antes de decisión del cliente
Disparadores P1	p. ej. >50% usuarios no completan checkout; riesgo de pérdida de datos
Responsable	Tú vs cliente vs ticket proveedor #

Comparte solo lectura con el contacto principal cuando la fila de línea base esté rellena. Celdas vacías = alto: captura al menos un número (incluso cronometraje manual) antes de depurar a fondo.

Paso 3 — Bisección sin heroicidades

Recorre el plan de arriba abajo. Documenta cada resultado en una línea: Comprobación → Resultado → Siguiente.

Orden típico en stacks de pyme:

1. Confirmar alcance (un usuario vs todos; un navegador vs todos; VPN on/off).
2. Comparar valle vs pico (descarta capacidad).
3. Revisar páginas de estado de terceros si hay APIs en el camino.
4. Inspeccionar despliegues recientes o plugins del cliente.
5. Abrir ticket a proveedor solo cuando tu lado esté descartado.

Si esperas login de prueba o export HAR del cliente, pausa el reloj SLA solo si tu SOW de retainer lo permite—y dilo por escrito.

Paso 4 — Cadencia Gmail (tres correos)

Correo 1 — Acuse (dentro del SLA de respuesta):

Asunto: [P2 Rendimiento] Investigando lentitud — brief adjunto

Bullets: lo que entiendes, lo medido, enlace al Google Doc, siguiente comprobación y ETA, horas máximas del time box.

Correo 2 — Punto medio (antes de la mitad del time box):

Resultados de bisección, qué queda descartado, qué necesitas del cliente, si te acercas a un disparador P1.

Correo 3 — Resuelto o escalado:

• Resuelto: métrica antes/después, categoría de causa, nota de prevención.
• Escalado a P1: indica umbral cumplido, modo incidente, nueva frecuencia de avisos.

Hilos cortos; el detalle vive en el doc.

Paso 5 — Opciones cuando el arreglo no es rápido

Si la bisección apunta a un proyecto mayor (consulta mala, caché ausente, migración), añade bloque Opciones al doc:

• A — Workaround (temporal, tope de horas)
• B — Arreglo definitivo (presupuesto de cambio)
• C — Pausar investigación hasta que el cliente aporte acceso/datos

Envía la elección en el correo 2 o 3. No absorbas horas de tuning sin límite.

Paso 6 — Regístralo en la revisión mensual del retainer

Añade una fila:

Mes	Tipo	Categoría causa	¿Repite?	Seguimiento
…	P2 rendimiento	p. ej. plugin cliente	S/N	p. ej. alerta monitorización

Conecta el evento con tu revisión mensual de retainer para ver patrones, no anécdotas.

Checklist QA antes de cerrar el ticket

• Línea base y métricas posteriores en el brief
• HECHO/SUPOSICIÓN revisado por una persona
• Cliente confirma resolución o aprueba vía CR
• Ningún ticket a proveedor huérfano
• Hilo Gmail alineado con marcas del doc

Por qué difiere de otros paquetes de retainer

• P1 urgente: caída mayor y cadencia de guerra.
• RCA post-incidente: aprendizaje tras estabilidad.
• Mantenimiento programado: cambios que tú planificas.
• Este paquete: lento-sin-caída con bisección medida primero y escalado explícito a P1 al cruzar umbrales.

Publica el brief antes de la siguiente hora de logs aleatorios. Tu yo futuro y tu cliente leerán números en lugar de renegociar qué significaba "lento".