Paquete de hipercare post-entrega con IA (ventana de soporte 30 días)

Cerraste el proyecto con un buen paquete de entrega. La web está en producción, los archivos en su drive y todo el mundo dijo gracias. Luego llega el lunes: tres avisos, un “cambio pequeño” que no lo es y un bug que puede ser alcance… o un error tuyo.

Ese primer mes caótico es hipercare: una ventana de soporte acotada y por escrito donde corriges defectos reales rápido, respondes dudas de uso con calma y cortas el scope creep gratis antes de que se coma el margen. Esta guía muestra a autónomos y agencias pequeñas cómo montar un paquete de hipercare post-entrega con IA en una tarde, con ChatGPT, un Google Doc y Gmail. Tú sigues enviando cada correo.

Por qué una ventana de 30 días gana a “escríbeme cuando quieras”

Sin límites, la semana del lanzamiento se convierte en diseño/desarrollo ilimitado gratis. Con límites, transmites más profesionalidad: no esquivas al cliente; ejecutas un mini programa de soporte.

La hipercare no es un retainer (para cadencia recurrente mira el email semanal de estado). Es un puente con fecha fin entre la entrega y el silencio o un plan de soporte de pago.

Al terminar tendrás:

• Una Política de Hipercare de una página
• Un registro de incidencias en Google Docs
• Prompts de ChatGPT para triaje bug / cómo se usa / cambio de alcance
• Plantillas de Gmail y resumen semanal
• Un email de cierre cuando acaba la ventana

Qué necesitas antes

• Alcance o SOW firmado (del documento de alcance o propuesta)
• Entrega con definición de “hecho”
• Canales que realmente monitorizas (normalmente email)

Herramientas: ChatGPT (o Claude), Google Docs, Gmail.

Paso 1 — Redacta la Política de Hipercare (una página)

Crea [Cliente] – Política Hipercare 30 días:

1. Ventana: fechas inicio/fin (30 días desde el sign-off de entrega).
2. Canales: email, asunto [Cliente – Soporte].
3. Plazo de respuesta: SLA honesto (p. ej. 1 día laborable).
4. Incluido: defectos del entregable, enlaces rotos, “¿cómo hago…?” sobre lo construido.
5. Excluido: funciones nuevas, páginas extra, caídas de terceros, carga de contenido salvo acuerdo.
6. Cambios: enlace mental al paquete de solicitud de cambio.

Esqueleto:

Ventana hipercare: [inicio] – [fin]
Contacto: [email], asunto [Cliente – Soporte]
Corregimos defectos del trabajo entregado sin coste en esta ventana.
Formación/dudas de uso: incluida si es razonable (≤30 min/semana agrupadas).
Peticiones nuevas: presupuesto aparte; trabajo tras aprobación por escrito.
Tras [fin]: soporte solo bajo [retainer / hora / ninguno].

Paso 2 — Registro de incidencias (segunda página del Doc)

Tabla:

| ID | Fecha | Quién | Resumen | Tipo (Bug/Uso/Cambio) | Estado | Notas |

Reglas de tipo:

• Bug: fallo vs especificación o regresión
• Uso: necesitan guía sobre lo entregado
• Cambio: resultado nuevo fuera del alcance → proceso CR

Paso 3 — Triaje de cada mensaje

Prompt de triaje en ChatGPT:

Eres asistente de operaciones para autónomos. Con el extracto del SOW y el mensaje del cliente, clasifica: Bug, Uso o Cambio. Un párrafo de razonamiento. Viñeta: siguiente acción para el profesional. No redactes aún la respuesta al cliente.

Extracto SOW:
[pega]

Mensaje cliente:
[pega]

Si es Cambio, no lo hagas gratis. Si es Bug, prioriza. Si es Uso, Loom o pasos breves.

Paso 4 — Borradores que tú envías

Redacta respuesta Gmail ≤120 palabras. Cercana, límites claros. Es [Bug/Uso/Cambio]. Si Cambio, indica que hace falta aprobación escrita y plazo tras presupuesto. Sin tono legal agresivo. Firma [Nombre].

Contexto:
[pega resumen triaje]

Tú pulsas enviar en Gmail.

Plantilla bug

Asunto: Re: [Cliente – Soporte] – registrado HC-004

Gracias por avisar. Lo registré como defecto de hipercare (HC-004) y objetivo [fecha] para [corregir/desplegar]. Actualizaré este hilo al cerrarlo.

Redirección a cambio de alcance

Asunto: Re: [Cliente – Soporte] – alcance nuevo

Encantado de ayudarte con [petición]. Queda fuera de lo firmado en esta fase; te envío resumen de cambio y presupuesto aparte. Tras tu OK por escrito, lo programo.

Paso 5 — Resumen semanal (opcional, muy útil)

Cada viernes: abiertos, cerrados, pendientes del cliente, cambios presupuestados, recordatorio de fecha fin. Misma cadencia que el email de estado semanal.

Prompt:

Convierte estas filas del registro en email semanal de hipercare ≤150 palabras, viñetas, sin jerga interna. Menciona que la hipercare termina el [fecha].

[pega filas]

Paso 6 — Cierra la ventana con claridad

Tres días antes del fin: email de salida con fixes, pendientes y qué pasa después (hora, retainer, nada). Si faltó sign-off formal, enlaza con aceptación de hito.

Asunto: Cierre ventana hipercare [fecha] – siguientes pasos

Nuestra hipercare de 30 días termina el [fecha]. Adjunto/enlace: snapshot final del registro. Abiertos: [lista o ninguno]. Tras [fecha], las peticiones serán [hora/retainer]. Gracias de nuevo por la colaboración.

Archiva el Doc como Hipercare – Final.

Errores habituales

• Arreglar “solo esta vez” un cambio → el cliente saltará el CR.
• Sin ventana escrita → hipercare infinita.
• Respuestas IA en automático → tono y riesgos legales.
• Sin registro → no demuestras qué hiciste gratis.

Dónde encaja en el ciclo con el cliente

Después de la entrega y antes del soporte de pago: descubrimiento → propuesta → arranque → entrega → hipercare (esta guía). Si el proyecto estaba en pausa, usa el paquete pausa/reanudación.

Más guías en Guías.

Resumen

1. Política de una página con fechas y límites.
2. Registro con tipos Bug / Uso / Cambio.
3. Triaje con ChatGPT; envío humano en Gmail.
4. Resumen semanal opcional; email de cierre obligatorio.

Gastarás menos energía emocional en el mes del lanzamiento—y el cliente sabrá qué significa “soporte gratis”.