Garantía y defectos post-entrega con IA

Autónomos y pequeñas agencias pierden margen en las semanas posteriores al lanzamiento cuando el cliente etiqueta cada idea nueva como “bug” y cada bug como cambio urgente. El periodo de garantía o responsabilidad por defectos del contrato (a menudo 30–90 días) no es lo mismo que el hipercare, la entrega del proyecto ni una solicitud de cambio de pago. Este playbook usa ChatGPT, Google Docs y Gmail para responder con rapidez, dejar por escrito qué entra en garantía y derivar el resto con orden.

Cuándo usar este pack

Úsalo cuando:

La entrega está firmada (o estás en la ventana post-lanzamiento del SOW).
El cliente dice que “algo está roto” o “no es lo acordado”.
Necesitas clasificar defecto vs cambio vs consulta de uso antes de volver a facturar horas.

No lo uses si aún estás en hipercare con reglas distintas, o si el encargo ya pasó a retainer de soporte.

Paso 1 — Captura el aviso sin discutir en el chat

Pide un mensaje estructurado por incidencia. Pega el texto del cliente en ChatGPT con:

Eres responsable de entrega. Separa HECHO (observable) de SUPOSICIÓN (interpretación).
Lista: pasos para reproducir, esperado vs actual, entorno, capturas/enlaces citados, y si parece (A) defecto del alcance entregado, (B) cambio/nueva función, (C) formación/consulta, (D) tercero/proveedor.
No prometas plazos ni soluciones.

Guarda la salida al inicio del documento de trabajo. Estás creando evidencia, no ganando una discusión.

Paso 2 — Clasifica antes de tocar código

La garantía cubre regresiones o incumplimiento de criterios de aceptación acordados. Mejoras, integraciones nuevas y peticiones “aprovecha que estás ahí” van al carril de cambio—aunque el cliente diga “bug”.

Loading diagram…

Separar defectos en garantía de solicitudes de cambio fuera de alcance en un brief escrito

Defecto (garantía): funcionaba en la aceptación y falla el mismo test, o nunca cumplió un criterio firmado.

Cambio: comportamiento nuevo, integración o alcance explícitamente fuera del hito.

Consulta de uso: permisos, contenido o flujo que el cliente aún no domina—responde con documentación.

Si dudas, clasifica por escrito en el brief; no absorbas alcance en silencio.

Paso 3 — Brief de un folio (Google Docs)

Duplica esta estructura en una carpeta compartida. Un documento por defecto; enlaza las CR aparte.

Sección	Qué escribir
Cabecera	Proyecto, fin de garantía, ID del defecto
Hechos	Pasos de repro, navegadores, roles, horas
Esperado vs actual	Cita criterios de aceptación o spec
Clasificación	Defecto / How-to / Cambio (una frase de motivo)
Impacto	Severidad; workaround si existe
Responsables	Quién corrige; quién valida en cliente
Plan de corrección	Rama, ventana de despliegue, rollback
Verificación	Pruebas que el cliente ejecutará para cerrar

Envía enlace en correo; el historial del chat no es tu sistema de registro.

Paso 4 — Cadencia en Gmail (tres correos)

Tono sereno y contractual sin sonar a abogado.

Acuse (mismo día hábil): “Recibimos el aviso #ID. Clasificación antes del [fecha]. La garantía termina el [fecha].”
Clasificación + plan: Enlace al brief. Si es defecto: ETA y qué necesitas. Si es cambio: plantilla de CR y pausa hasta aprobación. Si es consulta: respuesta corta + enlace.
Cierre por verificación: “Ejecutad las pruebas 1–3 del brief antes del [fecha]. Cerramos al confirmar o pasamos a CR #.”

Redacta los tres en ChatGPT y tú ajustas nombres, fechas y compromisos antes de enviar.

Paso 5 — Corrige, despliega y verifica

Solo para defectos en garantía:

Time-box de investigación (p. ej. 90 minutos) antes de escalar o hablar de CR.
Anota la última versión buena si hay rollback posible.
Tras el despliegue, actualiza la sección de verificación del brief.

Si afecta a auth, pagos o datos, pide ventana de despliegue explícita aunque sea garantía.

Paso 6 — Log de garantía (Google Sheets)

Una fila por aviso:

Columna	Ejemplo
Fecha	2026-11-07
ID	W-014
Clasificación	Defecto
Estado	Cerrado / CR-221
Días de garantía	12 de 60
¿Facturable?	No / Sí (CR)

Revisa el log cada semana. Muchos “how-to” indican runbook débil; muchos “cambio” indica expectativas flojas en la aceptación de hitos.

Prompts listos para pegar

Clasificación:

Con estos criterios de aceptación del SOW, clasifica este aviso. Salida: clasificación, información que falta pedir y 3 pruebas de verificación para el cliente.
Extracto SOW: [pegar]
Aviso: [pegar]

Pulir brief:

Convierte este triaje en un Brief de defecto en garantía en tabla, frases cortas. Marca lo que suene a creep de alcance.

Cómo debe quedar

Al cerrar la garantía: cada aviso numerado, defectos cerrados con verificación del cliente, cambios siempre con CR, y sin facturas sorpresa por alcance movido por DM. Al terminar la ventana, envía un resumen con pendientes y deriva a retainer o al pack de cierre de encargo si el proyecto termina.

Más guías prácticas en guides para autónomos y pymes que entregan proyectos con asistentes de IA—sin sustituir tu criterio, pero con un rastro escrito lo bastante rápido para cuidar la relación y el margen.