Paquete de escalación a proveedor tercero en retainer de soporte (con IA)

Tu retainer de soporte cubre diagnóstico, coordinación y arreglos pequeños que puedes entregar—no controlar el calendario de releases de otra empresa. Cuando la causa raíz está en un SaaS, pasarela de pago, hosting o ISV, el cliente igual espera actualizaciones tranquilas y un plan por escrito. Sin eso, cada día de silencio del proveedor parece tu incumplimiento de SLA—aunque el bloqueo sea externo.

Este playbook es para retainers activos cuando ya abriste (o confirmaste) un ticket con un tercero y necesitas un puente de estado: quién debe actuar, qué debe hacer el cliente, cómo se consumen las horas bloqueado y cuándo pasar a un workaround de pago. Complementa tu pack de incidente urgente (respuesta interna en vivo) y el pack de incumplimiento SLA (cuando tú fallaste una ventana)—no los sustituye.

Más guías paso a paso en Guías.

Cuándo usar este pack

Úsalo cuando todo esto se cumple:

• El ticket del retainer está abierto y reprodujiste o aislaste el problema con credibilidad.
• La siguiente acción relevante es del proveedor (bug, aprovisionamiento, certificado, revisión de abuso, caída del carrier).
• El cliente pregunta «¿qué pasa?» mientras el ticket del vendor está en «Waiting on vendor» o equivalente.

No lo uses si el trabajo es fuera de alcance (desarrollo nuevo, formación larga)—aplica el pack de derivación fuera de alcance.

Qué vas a entregar

1. Un Puente de estado con proveedor de una página en Google Docs (ID de caso, timeline, acciones del cliente, política de horas).
2. Una secuencia de Gmail (ack → estado programado → cierre o pivot).
3. Una línea en la revisión mensual para que los días bloqueados no desaparezcan del informe.

Herramientas: ChatGPT (clasificación + borradores), Google Docs (fuente única), Gmail (comunicación al cliente—envías tú).

Paso 1 — Clasificar propiedad (HECHO vs SUPOSICIÓN)

Pega un resumen sanitizado en ChatGPT: síntomas, lo que probaste, estado en el portal del vendor y fragmentos de contrato (sin contraseñas ni PII completa).

Prompt de ejemplo:

Eres un lead MSP senior. Etiqueta cada viñeta HECHO (verificado) o SUPOSICIÓN (probable sin prueba).
Luego indica: (1) quién debe dar el siguiente paso—nosotros, cliente o proveedor; (2) riesgos visibles para el cliente si el SLA del vendor es 3–10 días; (3) tres políticas de horas bloqueado: pausar facturable, tope diario de seguimiento, o seguir workaround activo.
Solo viñetas.

Regla humana: Si la propiedad no está clara, invierte una hora acotada en pruebas (logs, status page, pasos reproducibles)—luego congela el doc puente. No quemes el banco del retainer refrescando el mismo estado.

Paso 2 — Redactar el Puente de estado (Google Docs)

Crea un doc con este esqueleto:

Sección	Contenido
Resumen	Una frase: qué falla y para quién
Responsable del siguiente paso	Proveedor / Cliente / Nosotros
Caso del proveedor	URL o ID, fecha de apertura, severidad
Acciones del cliente	Aprobaciones, DNS, contacto de facturación, ventana de prueba
Nuestras acciones en espera	Revisión diaria del portal, workaround interno, cadencia de avisos
Política de horas bloqueado	Elige una: pausa tras X h, tope Y min/día, o solo facturar workaround
Disparadores de pivot	Si no hay movimiento antes de FECHA → Opciones A/B/C (CR workaround, downgrade, escalar account manager)
Última actualización	Fecha + nombre

Comparte lectura o comentario con el contacto principal. Enlaza este doc en cada Gmail para anclar la conversación.

Paso 3 — Secuencia Gmail (envías tú)

Correo 1 — Mismo día (ack + enlace)

Asunto: [Retainer] Escalación proveedor — [issue corto] — puente de estado

Cuerpo: enlace al doc, ID del caso, política de horas bloqueado explícita y fecha del próximo update (aunque sea «sin novedad»).

Correo 2 — En cadencia (cada 2–5 días laborables o cuando el vendor se mueva)

Tres viñetas: cambio de estado (o «sin cambios»), acción del cliente (o «ninguna»), próxima revisión.

Correo 3 — Cierre o pivot

Fix verificado + qué monitorizaste, o pivot a solicitud de cambio / presupuesto de workaround—doc actualizado a Cerrado o Pivot.

ChatGPT puede redactar cada correo desde el doc; tú verificas hechos y pulsas enviar.

Vista del flujo

Paso 4 — Reglas de horas (escríbelas antes del resentimiento)

Elige una política y ponla en el doc antes del día tres de silencio:

• Pausa: El reloj facturable para mientras el vendor actúa, salvo workaround aprobado.
• Tope: 15–30 minutos por día laborable para portal + aviso al cliente (documentar en revisión mensual).
• Workaround activo: El cliente aprobó scope extra; si el build crece, trátalo como solicitud de cambio.

Cita el SOW del retainer si menciona dependencias de terceros—no inventes créditos; ofrece opciones por escrito como en el pack de SLA cuando tú retrasaste, no cuando el panel de Stripe está en rojo.

Paso 5 — Log para la revisión mensual

Añade una fila:

Bloqueo vendor | [Producto] | [ID caso] | [Días bloqueado] | Política horas: [pausa/tope/workaround] | Resultado

Esa línea alimenta tu revisión mensual del retainer sin convertir la llamada en culpa por una caída ajena.

Errores habituales

• Desaparecer porque el vendor va lento—el cliente cree que soltaste el ticket.
• Quemar horas refrescando el mismo «Investigating» sin valor nuevo.
• Prometer fechas del vendor que no controlas—usa rangos y «última comprobación».
• Saltarse el doc puente y dejar todo en un hilo caótico.

Checklist rápido

• Propiedad HECHO/SUPOSICIÓN
• ID de caso en el doc
• Política de horas bloqueado acordada por escrito
• Gmail ack con enlace el mismo día
• Fecha pivot antes de que el workaround crezca solo
• Fila en revisión mensual

En resumen

Los bloqueos de terceros son normales en stacks modernos. Tu valor en esas semanas es claridad: un doc, emails predecibles, horas honestas y un camino de pivot cuando se acaba el reloj del proveedor—not fingir que tú publicas su parche.