Retainer de soporte: paquete de fallo de automatización e integración (con IA)

Cuando un cliente con retainer de soporte activo dice «Make dejó de funcionar» o «ya no entran leads al CRM», el fallo suele ser silencioso: el panel se ve bien, pero las ejecuciones llevan días paradas o fallan siempre en el mismo paso. Necesitas un camino tranquilo y facturable: separar hechos de suposiciones, documentar qué se rompió, conseguir aprobación por escrito antes de reautorizar o tocar producción, y mantener una cadencia clara en Gmail hasta que pase una prueba de extremo a extremo.

Este playbook cubre fallos de integraciones y automatizaciones en soporte retainer (Make, Zapier, n8n, webhooks propios, conectores formulario↔CRM)—no entregabilidad de email ni DNS, no rollback de un despliegue malo, ni caída total del sitio. Combina ChatGPT para triaje estructurado, un Integration Status Brief de una página en Google Docs y una secuencia de tres correos en Gmail que el cliente pueda reenviar internamente.

Más guías paso a paso en nuestra biblioteca de guides.

Cuándo usar este paquete

Ábrelo cuando se cumplan todas estas condiciones:

• El retainer está activo y el ticket entra en alcance (arreglo sobre automatizaciones existentes).
• Dejó de moverse data o las ejecuciones fallan en bucle (no un blip puntual ya cerrado).
• Tienes acceso al historial de ejecuciones, logs o un ID de registro de prueba que al cliente le importe.

Si la causa es una caída del proveedor sin acción posible de tu lado, pivota al pack de escalación a terceros tras la primera hora bloqueada. Si el sitio está caído por completo, usa el pack de incidente P1 urgente.

Flujo en seis pasos

Paso 1 — Captura hechos antes de tocar nada

Pega en ChatGPT (sustituye lo entre corchetes):

Eres mi asistente de triaje de integraciones. Etiqueta cada línea HECHO (evidencia) o SUPOSICIÓN (supuesto).

Síntoma: [cita del cliente]
Plataforma: [Make / Zapier / n8n / URL webhook]
Última ejecución OK (fecha + ID registro): [del historial]
Primera ejecución fallida (fecha + error): [pega]
Cambios recientes: [OAuth / contraseña / campo CRM / bajada de plan]
Registro prioritario: [ej. lead test@…]

Salida:
1) Clase de fallo: auth | cuota | mapeo | API upstream | escenario desactivado
2) Tres comprobaciones seguras (sin escrituras en prod)
3) Preguntas al cliente (máx. 5)

Guarda el hilo o copia el resumen: pegarás el bloque HECHO en el brief.

Paso 2 — Arma el Integration Status Brief (Google Docs)

Estructura de una página:

Sección	Contenido
Cabecera	Cliente, nombre del escenario, ID ticket, fecha
Impacto	Qué se detuvo (ej. «Shopify → HubSpot desde mar 14:00 UTC»)
Línea temporal	Última OK → primera KO (solo HECHOS)
Clase de error	auth / cuota / mapeo / upstream / desactivado
Evidencia	Capturas o logs (tacha secretos)
Fix propuesto	Pasos + horas retainer estimadas
Rollback	Cómo revertir si empeora
Verificación	Registro de prueba + resultado esperado

Comparte el doc solo comentarios hasta que aprueben reconexión o cambios en producción.

Paso 3 — Cadencia Gmail (tres emails)

Email 1 — Reconocer + enlace al brief (dentro del SLA)
Asunto: [Retainer] Incidencia integración — hechos capturados, brief adjunto
Cuerpo: síntoma en una frase, enlace al Google Doc, qué necesitas (ej. «confirmar que podemos reconectar Make a HubSpot») y cuándo llega la siguiente actualización—aunque sigas investigando.

Email 2 — Punto de decisión o avance
Envía cuando conozcas la clase de error o falte aprobación: repite HECHO vs preguntas abiertas, opciones A/B (re-auth ahora vs esperar a IT del cliente) e impacto en horas si el banco retainer está justo.

Email 3 — Fix verificado o aplazamiento explícito
Incluye: payload de prueba, marca de tiempo de ejecución OK, enlace a la sección «Verificación» del brief y qué vigilar (caducidad OAuth, reset de cuota API).

Deja los tres en el hilo del ticket para trazabilidad de facturación y RCA.

Paso 4 — Arreglo con matriz de verificación

Antes de cerrar:

1. Un payload de prueba — registro real o anonimizado que el cliente nombró.
2. Comprobación downstream — fila CRM, mensaje Slack o línea en hoja.
3. Idempotencia — repite una vez; evita duplicados en prod salvo que sea intencional.
4. Ventana de monitor — anota «vigilar hasta [hora]» por colas retardadas.
5. Actualiza doc — bloque verde de verificación; archiva hilo ChatGPT.

Arreglos frecuentes (documenta cuál aplicó): reconectar OAuth, API key nueva en vault, mapa de campos tras cambio de esquema CRM, escenario reactivado tras baja de plan, URL webhook tras cambio de dominio.

Paso 5 — Comprobaciones rápidas en Make (opcional)

Si el stack es Make, verifica en orden: escenario no pausado, conexión «connected», cuota de operaciones y el módulo exacto que se puso rojo en el historial. No reproduzcas bundles viejos en masa hasta que el cliente acepte riesgo de duplicados.

Paso 6 — Anótalo en la revisión mensual del retainer

Añade una fila al log de salud: fecha, plataforma, clase de error, horas consumidas, acción preventiva (ej. «auditoría OAuth trimestral», «alerta si 24 h sin ejecuciones»). Esa fila alimenta tu revisión mensual de retainer.

Qué no es este paquete

• Rebotes/spam y DNS de email — usa el pack de entregabilidad (SPF/DKIM/DMARC).
• Rollback de release malo — brief con última build buena y smoke tests.
• Automatización nueva de alcance — deriva a solicitud de cambio si quieren flujo neto nuevo.

Texto para el cliente (copiar/pegar)

Hemos documentado la incidencia de integración en un brief (hechos, línea temporal, fix propuesto). No reconectaremos APIs ni cambiaremos mapeos en producción hasta que respondáis aprobado en el doc. Próxima actualización a las [hora]. La verificación usará [ID registro] para que confirméis en [sistema].

Usado con honestidad, este pack convierte «la magia de la automatización se paró» en un entregable retainer escrito y verificable—sin arreglos misteriosos ni re-auth silencioso que el cliente descubre tarde.