Puente estabilización → hipercare en proyectos cliente (con IA)

Las primeras 72 horas tras el corte a producción son ruidosas: alertas, capturas reenviadas y cada señal parece urgente. Un paquete de estabilización post-corte ordenado evita perseguir ruido u olvidar un defecto real. Pero cuando llega la hora 72, muchos autónomos y equipos pequeños dejan de documentar y caen en soporte informal por chat. Ese hueco genera disputas de facturación, tickets duplicados y clientes que creen que el hipercare es rediseño ilimitado.

Este playbook es el puente estabilización → hipercare: el momento escrito en el que cierras la ventana de estabilización, trasladas el registro de vigilancia y abres la ventana de hipercare de 30 días con reglas claras. Usarás ChatGPT como editor estructurado (disciplina FACTO vs SUPOSICIÓN), Google Docs para un Brief de transición de una página, Google Sheets para continuidad del registro y Gmail para un traspaso T+72 deliberado—no un vago "ya estamos en soporte".

Qué es este puente (y qué no)

Es: un reinicio contractual entre "vigilar el sistema recién nacido" y "triar el uso en vivo 30 días".

No es:

• La ejecución del día de corte
• El manual completo de hipercare (ya tienes ese pack)
• La garantía de defectos tras hipercare
• Una propuesta de retainer (déjala para el cierre de hipercare)

Si saltaste una ventana de estabilización escrita, haz un cierre abreviado igualmente: es mejor ser explícito que fingir que el puente existió.

Prerrequisitos

Antes de puentear, conviene tener:

1. Registro de estabilización (Sheets) con filas MONITOR, FIX, RUIDO o ESCALAR
2. Brief de estabilización en Google Docs de las 72 h
3. Política de hipercare (alcance, canales, plazos) ya compartida
4. Contacto principal y aprobador del cliente por escrito

Flujo de punta a punta

Paso 1 — Cierre en ChatGPT (FACTO vs SUPOSICIÓN)

Pega la exportación del registro y el esquema del Brief de estabilización. Pide separar FACTO (eventos con hora, versiones desplegadas, IDs de ticket) de SUPOSICIÓN (ánimo del cliente, causas adivinadas). Solicita:

• Top 5 resueltos con nota de verificación
• Top 5 abiertos con severidad y responsable
• Patrones de ruido a ignorar en hipercare (formación vs defecto)
• Prioridades hipercare sugeridas para la semana 1

Regla humana: si una línea no tiene ID de ticket o fila de registro, bájala a SUPOSICIÓN o elimínala.

Paso 2 — Brief de transición en Google Docs (una página)

Crea Brief de transición — [Cliente] — Cierre estabilización / Apertura hipercare. Secciones:

Sección	Propósito
Ventana cerrada	Fin estabilización con zona horaria
Hipercare abierto	Fechas inicio y fin, horario de cobertura
Tabla incidencias abiertas	ID, severidad, estado, siguiente acción
Diferidos	Fuera de hipercare explícito (→ CR)
Canales y SLA	Dónde ticketar; qué no es ticket
Criterios de éxito	Qué es "semana 1 sana" en hipercare

Comparte enlace solo lectura en Gmail; cambios de alcance vía solicitud de cambio.

Paso 3 — Traspaso del registro en Google Sheets

Duplica la pestaña estabilización a Registro hipercare (no borres histórico). Columnas:

• issue_id, abierto_estabilizacion, clase (defecto / cómo-hacer / cambio), severidad, estado, responsable, visible_cliente

Añade semana_hipercare. Congela fila 1. Archivar la pestaña estabilización marca que el puente es real.

Paso 4 — Secuencia Gmail T+72

Un email intencional (no volcar un hilo):

Asunto: [Proyecto] Estabilización cerrada → Hipercare desde [fecha]

Bloques:

1. Qué vigilamos (72 h) — dos frases, solo FACTO
2. Qué corregimos — viñetas con verificación
3. Qué queda abierto — enlace a tabla del Brief
4. Cómo trabajar ahora — canal, horario, qué requiere aprobación
5. Reconocimiento — "Responde ACK para confirmar términos hipercare antes de [fecha]"

Recordatorio T+78 opcional; si silencio, sigue términos del brief y anota no-respuesta en el registro.

Paso 5 — Ritmo semana 1 en hipercare

El éxito del puente se mide en siete días:

• Barrido interno diario de 15 min del registro (sin spam al cliente)
• Un resumen visible para el cliente a fin de semana 1 (temas, no cada micro-arreglo)
• Cualquier ítem cambio va a tu flujo de solicitud de cambio—no creep silencioso

Copiar-pegar: prompt ChatGPT

Eres asistente editorial para entrega freelance/PYMES.
Entrada: CSV registro estabilización + notas del brief.
Salida:
1) Lista FACTO (con hora y fuente)
2) Lista SUPOSICIÓN (etiquetada)
3) Tabla abiertos: id, severidad P0-P2, responsable, visible_cliente sí/no
4) Patrones ruido a descartar en hipercare
5) Prioridades semana 1 (máx 5)
Reglas: no inventar IDs; si desconocido escribe UNKNOWN.

Copiar-pegar: esqueleto Brief de transición

# Brief de transición — [Cliente] — Estabilización → Hipercare

## Ventanas
- Estabilización cerrada: [fecha hora TZ]
- Hipercare: [inicio] a [fin]

## Incidencias abiertas
| ID | Resumen | Sev | Responsable | Siguiente paso |

## Fuera de alcance (hipercare)
- ...

## Canales
- Tickets: ...
- Emergencia: ...

## ACK cliente
Responder ACK antes de [fecha].

Errores frecuentes

1. Cierre blando — "avisad si falla" sin ACK → creep de alcance
2. Amnesia del registro — tickets nuevos sin enlace a filas de estabilización
3. Mezclar formación y defectos — etiqueta cómo-hacer aparte
4. Sin lista de diferidos — el cliente asume que harás v2 gratis

Checklist antes de enviar

• Hora fin estabilización en zona del cliente
• Fecha fin hipercare = SOW
• Incidencias abiertas con responsable
• Cambios apuntan a CR
• Enlace del brief accesible para cuenta Google del cliente
• Fecha límite ACK indicada

Dónde encaja en el ciclo

Ya corriste UAT, corte y estabilización 72 h. El puente hace que el hipercare empiece en papel, no en el folklore de Slack. Al cerrar hipercare, usa tu pack de cierre y feedback y entonces plantea retainer.

Más guías en guides.