Paquete de estabilización post-corte (primeras 72 h, con IA)

La hora tras el corte a producción rara vez es tranquila: suben los logs, el cliente reenvía capturas y cada alerta parece P1. Autónomos y equipos pequeños que no definen una ventana de estabilización escrita queman confianza persiguiendo ruido o pierden un defecto real que encaja en garantía. La estabilización post-corte son las primeras 72 horas tras el go-live: vigilar señales en vivo, separar fricción esperable de defecto y cerrar con un traspaso firmado al hipercare. No es UAT, no es la ejecución del corte y no es el flujo de garantía de defectos.

Este paquete combina ChatGPT para clasificar señales FACTO/SUPOSICIÓN, un Brief de Estabilización en Google Docs, un registro de monitorización en Google Sheets y tres correos en Gmail en T+0, T+24 y T+72. Más guías en DoAIWork para playbooks de entrega.

Cuándo abrir el pack de estabilización

Aplícalo cuando todo esto sea cierto:

• El corte a producción terminó con go escrito (o rollback controlado documentado).
• Los sistemas visibles para el cliente están en vivo y hay un responsable nombrado para los tres primeros días.
• Existe al menos un canal observable: logs, analítica, bandeja de soporte o chequeos sintéticos.
• Los límites de hipercare o garantía existen pero aún no son “soporte normal”.

No lo uses si el corte sigue en curso, quedan bloqueos de UAT o el cliente pausó el proyecto—usa pausa/reanudación.

Flujo de punta a punta

Paso 1 — Clasificar señales (ChatGPT)

Pega alertas anonimizadas, fragmentos de soporte y capturas de métricas. Obliga FACTO vs SUPOSICIÓN:

Eres el responsable de entrega en la hora 2 tras el corte a producción.
Lista cada señal como FACTO (observado) o SUPOSICIÓN (inferido).
Por cada FACTO asigna: VIGILAR (24h), CORREGIR (defecto en alcance), RUIDO (fricción de lanzamiento) o ESCALAR (caída/rollback).
Salida en tabla: señal | fuente | clase | responsable | próxima revisión.

Tu trabajo es clasificar, no adivinar la causa raíz en solitario.

Paso 2 — Brief de Estabilización (Google Docs)

Documento compartido con:

1. Alcance — URLs, entornos, build ID, enlace al corte.
2. Métricas vigiladas — tres que el cliente entienda (errores, conversión, login).
3. Umbrales — amarillo (vigilar) vs rojo (avisar on-call) con números.
4. Roles — quién aprueba hotfixes, quién habla con usuarios, quién abre ticket a proveedor.
5. Criterios de paso a hipercare — qué significa “lo bastante estable” antes del mes de hipercare.

Cliente en solo lectura; tu equipo con edición.

Paso 3 — Registro en Google Sheets

Columnas útiles bajo presión:

Marca UTC	Señal	Fuente	Clase	Responsable	Estado	¿Visible cliente?	Notas
			VIGILAR/CORREGIR/RUIDO/ESCALAR		Abierto/En curso/Hecho	S/N

Fila resumen a T+72: CORREGIR cerrados, ESCALAR abiertos, umbrales en verde 24h seguidas.

Paso 4 — Cadencia Gmail (tres correos)

T+0 (≤2h tras corte): confirmar vivo, métricas vigiladas, enlace al Brief, avisar que habrá ruido normal.

T+24: tabla de CORREGIR/VIGILAR/RUIDO, acciones del cliente si las hay.

T+72: cierre de estabilización o extensión motivada; fecha y canal de hipercare.

Asuntos: [Proyecto] Estabilización — T+0|T+24|T+72.

Paso 5 — Cuándo escalar o absorber

Situación	Acción
Ajuste de contenido menor	RUIDO — registrar, arreglar si es rápido
Checkout/login roto para muchos	ESCALAR — triggers de rollback del corte
Caso borde de un usuario	CORREGIR — brief en Doc, ventana de parche
Pico dentro de banda amarilla	VIGILAR — tendencia en mail T+24

Patrones crónicos en retainer van al pack de tickets recurrentes, no a estabilización.

Paso 6 — Cerrar estabilización formalmente

Cierra cuando:

• No hay ESCALAR abiertos.
• Cada CORREGIR tiene verificación en la hoja.
• El cliente confirma el mail T+72 (inicio hipercare o garantía).
• El build en producción coincide con el Brief.

Archiva enlaces del Doc y la hoja; sirven de prueba en una disputa de garantía.

Párrafo para cliente (T+72)

Cerramos la ventana de estabilización de 72 horas a [fecha/hora TZ].
El build [ID] cumplió los umbrales acordados. El hipercare empieza [fecha]
por [canal]. Envíe incidencias nuevas por [intake] para clasificar
defecto vs consulta según nuestra política de hipercare.

Cómo se ve el éxito

• El cliente recibe actualizaciones con estructura, no pings sueltos.
• El equipo no trata cada miss de caché como catástrofe.
• El hipercare arranca con línea base clara, no incendios sin registrar.

Errores frecuentes

• Confundir estabilización con soporte ilimitado gratuito en lugar de ventana acotada.
• Omitir la hoja porque “lo recordaremos”—el cliente no.
• Enviar el “todo bien” de T+0 antes de terminar humos sintéticos.
• Abrir hipercare sin notas de verificación en ítems CORREGIR.

La estabilización es breve, pero protege todos los playbooks que vienen después.