SOP de handoff de Sales a CS

El handoff de Sales a CS es donde nacen la mayoría de los problemas de onboarding. El AE cierra, pasa al siguiente deal, y el CSM hereda un registro de HubSpot con una etapa closed-won, un valor de contrato y casi nada sobre por qué el cliente compró o qué se le prometió. El CSM gasta la primera llamada de kickoff redescubriendo el deal en vez de impulsar el onboarding. Este SOP arregla eso con tres cosas: un conjunto fijo de campos de handoff que el AE llena antes de que el deal se marque como closed-won, una regla de timing que ata el handoff a la etapa del deal en vez de a la memoria, y una secuencia de kickoff que corre igual cada vez. Es deliberadamente aburrido. Un handoff que depende de que el AE se acuerde de escribir un buen mensaje de Slack es un handoff que falla la semana en que el AE está de PTO.

El bundle del artifact vive en apps/web/public/artifacts/sales-to-cs-handoff-sop/. Incluye handoff-sop.md (el procedimiento en sí, listo para pegar en Notion o una base de conocimiento de HubSpot), handoff-fields.csv (el manifiesto de campos con tipos y flags de requerido/opcional para que el admin de HubSpot los provisione), y slack-handoff-template.md (el mensaje canónico de canal que el AE postea). Adapta los tres a tus nombres de campos y convenciones de canal antes del rollout.

Cuándo usar esto

Usa este SOP cuando tienes un equipo de Sales y un equipo de CS distintos —un AE que posee el deal hasta el cierre y un CSM que posee al cliente después— y el handoff entre ellos es informal o no documentado. El síntoma clásico es un CSM abriendo cada llamada de kickoff preguntándole al cliente cosas cuya respuesta el AE ya sabía: quién es el sponsor ejecutivo, cómo se ve el éxito en 90 días, por qué te eligieron sobre el incumbente. Cada una de esas preguntas es un pequeño impuesto sobre la relación, y el cliente lo paga.

Encaja mejor para equipos en el rango de 100 a 2,000 clientes corriendo sobre HubSpot como el CRM y Slack como la capa de comunicación interna. Por debajo de ~100 clientes el AE y el CSM suelen ser la misma persona o estar lo bastante cerca como para que un SOP documentado sea overhead. Por encima de ~2,000 probablemente necesitas una plataforma de CS (Gainsight, Catalyst, Vitally, ChurnZero) impulsando el handoff vía una CTA en vez de una propiedad de deal de HubSpot y un post de Slack —a esa escala el post manual es lo que se salta. Este SOP es la herramienta correcta en la banda donde el proceso importa pero el presupuesto de tooling todavía no justifica un CSP dedicado.

Cuándo NO usar esto

No lo adoptes si tus AEs no son responsables de la calidad de datos al cierre. El SOP es tan bueno como los campos, y los campos solo se llenan si “closed-won requiere el bloque de handoff completo” se hace cumplir —por una regla de campo-requerido de HubSpot, un gate de etapa de deal, o un manager que rebota la comisión hasta que esté hecho. Sin esa imposición obtienes campos a medio llenar que son peores que ninguno, porque el CSM confía en ellos y se quema.

No lo uses como sustituto de que el AE y el CSM realmente hablen. Los campos cargan los hechos estructurados; no cargan la textura —el champion que está privadamente nervioso por la adopción, el contacto de procurement que peleó el deal, la feature que el AE medio prometió en la última llamada. La llamada de warm handoff de 15 minutos en la secuencia de abajo es donde ese contexto se transfiere. Saltarla y confiar solo en los campos produce handoffs técnicamente-completos que aun así se pierden lo que hunde el renewal.

No le pegues esto a un motion de renewal o expansión. Este SOP tiene alcance al handoff de logo nuevo: AE a CSM, una vez, al cierre. Los renewals y expansiones tienen dueños distintos y señales distintas, y forzarlos a través de esta plantilla produce ruido.

Los campos de handoff

Estos viven como propiedades de deal o company de HubSpot para que viajen con el registro y sean consultables después. El manifiesto en handoff-fields.csv los provisiona. El conjunto requerido, cada uno lleno antes de closed-won:

• Sponsor ejecutivo (referencia de contacto) —la persona cuyo presupuesto es este y quien tomará la llamada de renewal. No el champion del día a día; el comprador económico.
• Champion del día a día (referencia de contacto) —con quién trabaja el CSM semanalmente. A menudo distinto del sponsor.
• Por qué compraron (texto largo) —el trigger de negocio real en una o dos oraciones. “El renewal de la herramienta legacy era 3x nuestro precio” es útil; “querían mejores analytics” no.
• Éxito definido / la métrica (texto largo) —lo que el cliente dijo que se ve como ganar, idealmente un número con una fecha. Esto se vuelve la estrella polar del success plan.
• Prometido en el deal (texto largo) —cualquier cosa a la que el AE se comprometió que no está en el contrato estándar: una integración custom, una fecha específica de go-live, una feature en el roadmap. Este es el campo que previene las peores fallas de handoff.
• Alcance contratado (estructurado) —seats, productos/SKUs, ARR, fechas de inicio y renewal de contrato.
• Entorno técnico (texto largo) —el CRM, data warehouse, proveedor de SSO, y cualquier integración que el cliente espera el día uno.
• Riesgos conocidos (texto largo) —el contacto de procurement que empujó de vuelta, la herramienta interna competidora, el equipo de usuarios finales escéptico. Sacado a la luz ahora o descubierto a las malas después.

Dos campos opcionales se ganan su lugar cuando están presentes: grabaciones de llamadas (link a la librería de Gong/grabaciones para las llamadas clave del deal) y timeline de decisión (cuánto corrió la evaluación y quién más estaba en la sala), que le dice al CSM cuánto peso organizacional carga la compra.

La regla de timing

El handoff está gated en la etapa del deal, no en el calendario del AE. La regla: el bloque de handoff debe estar completo antes de que el deal pueda moverse a closed-won, y la llamada de warm handoff debe ocurrir dentro de tres días hábiles del cierre. Atarlo a la etapa en vez de a un recordatorio es el punto entero —un recordatorio se pospone; un gate de etapa lo hace cumplir el pipeline. En HubSpot esto es una regla de propiedad-requerida-en-etapa más un workflow que postea a Slack al cambio de etapa.

La secuencia de kickoff

1. El AE completa el bloque de handoff antes de marcar closed-won. El gate de etapa de HubSpot rehúsa el movimiento de lo contrario.
2. El workflow de HubSpot postea a #cs-handoffs al cambio de etapa a closed-won, usando la plantilla en slack-handoff-template.md: company, ARR, sponsor, champion, por-qué-compraron, la métrica, cualquier cosa prometida, y un link al registro del deal. El post @-menciona al CSM asignado.
3. El CSM reconoce en el thread dentro de un día hábil —una reacción no es reconocimiento; un CSM tiene que confirmar que ha leído el campo de prometido-en-el-deal específicamente.
4. El AE + CSM corren una llamada de warm handoff de 15 minutos dentro de tres días hábiles. Agenda: recorrer los riesgos conocidos, confirmar los ítems prometidos, transferir la textura de la relación que los campos no pueden contener. Esto se registra como una meeting de HubSpot en el registro.
5. El CSM agenda el kickoff externo con el cliente, habiendo ya leído el deal. El cliente nunca re-explica por qué compró.

Cómo se ve el éxito

Rastrea tres números. Primero, completitud del handoff —el porcentaje de deals closed-won con cada campo requerido lleno. El gate de etapa debe llevar esto a casi 100% dentro de dos semanas; si se queda más bajo, el gate no se está haciendo cumplir realmente y estás corriendo sobre el sistema del honor. Segundo, tiempo-a-kickoff —días desde closed-won hasta la llamada de kickoff externo. Apunta a una mediana bajo siete días hábiles; un lag más largo significa que el momentum de compra del cliente se está decayendo antes de que el onboarding arranque. Tercero, la tasa de redescubrimiento —encuesta a los CSMs mensualmente: “en tus últimos cinco kickoffs, ¿cuántas veces tuviste que preguntarle al cliente algo que el AE debió haber registrado?” Apunta a cero. Cualquier cosa por encima de uno por kickoff significa que los campos están presentes pero no se confía en ellos, lo que usualmente se rastrea a AEs llenándolos con relleno para pasar el gate.

Versus las alternativas

Versus un handoff de Slack en texto libre. El status quo en la mayoría de los equipos es el AE posteando un mensaje no estructurado en un canal cuando se acuerda. Es más rápido de escribir y peor en todo lo demás: no es consultable, no se hace cumplir, su calidad oscila con el humor del AE, y se desvanece en el scroll del canal. La versión de campos estructurados le cuesta al AE tal vez tres minutos extra por deal y hace el handoff auditable. Elige texto libre solo si tu volumen es tan bajo (bajo ~5 handoffs al mes) que la estructura no vale la pena del setup.

Versus una CTA de plataforma de CS (Gainsight, Catalyst, Vitally, ChurnZero). Un CSP puede disparar una CTA de handoff automáticamente al closed-won, enrutarla, y rastrear la completitud nativamente —mecánica estrictamente mejor que HubSpot-más-Slack. El trade-off es costo y setup: un CSP corre cinco cifras anuales y semanas para implementar. Si ya posees uno, impulsa el handoff a través de él y usa la lista de campos y la secuencia de este SOP como el contenido. Si no, este SOP te da el 80% del valor al costo de provisionar ocho propiedades de HubSpot y un workflow.

Versus no hacer nada. Viable solo si el AE y el CSM son la misma persona o comparten escritorio. En el momento en que los dos roles se separan, el handoff no documentado se vuelve la mayor fuente individual de churn temprano prevenible —el cliente que hace churn en el mes cuatro porque la integración que el AE prometió nunca estuvo en el roadmap.

A vigilar

• Campos llenados con relleno para pasar el gate. En el momento en que closed-won está gated en la completitud de campos, los AEs tienen un incentivo de teclear “n/a” o “ver notas” para pasarlo. Guarda: haz la llamada de warm handoff obligatoria y haz que el CSM rechace el handoff en el thread si los campos de prometido-en-el-deal o métrica-de-éxito están vacíos o son basura —el AE no consigue que el deal se cuente como limpiamente entregado hasta que el CSM lo acepta.
• El campo de prometido-en-el-deal dejado en blanco. Esta es la omisión de mayor costo: un compromiso verbal que el AE hizo y olvidó, que el cliente recuerda y espera. Guarda: haz este campo requerido incluso cuando esté vacío forzando una entrada explícita de “nada prometido más allá del contrato”, para que un blanco sea una declaración deliberada en vez de un descuido.
• El post de Slack se dispara pero nadie posee el reconocimiento. Un handoff posteado a un canal al que ningún CSM está asignado es un handoff al vacío. Guarda: el workflow de HubSpot @-menciona al CSM asignado específico por mapeo de deal-owner-a-CSM, y el SOP requiere un reconocimiento en el thread dentro de un día hábil, rastreado por el lead de CS.
• El SOP deriva conforme el schema del CRM cambia. Una propiedad de HubSpot renombrada o una nueva etapa de deal rompe silenciosamente el workflow que postea a Slack. Guarda: revisa el manifiesto de campos en handoff-fields.csv contra las propiedades vivas de HubSpot una vez por trimestre, y mantén la lista de campos de la plantilla de Slack en sync con los nombres de las propiedades de deal.