Dentro de un año, tu cliente no renovará contra el contrato, sino su expectativa de qué firmó.
Durante años pensé que un buen handover era un buen documento, algo que quedara clarlo para traspasar la información como: contrato, alcance, contactos, condiciones, fechas… Todo ordenado, todo completo, todo transferido para que el CSM lo tuviera todo en un documento.
¿La realidad? Algunos proyectos seguían arrancando torcidos.
Hasta que con etiempo entendí que ese “documento” movía datos de un lugar a otro pero no traspasaba la información que realmente hacía falta, la información que no aparecía en ningún CRM y te cuento a continuación.
Lo que de verdad llega roto
Cuando un cliente firma con tu compañía, no compra un alcance, lo que compra es una idea de lo que va a pasar después.
Se ha imaginado algo, una situación en la que se ve él o en equipo dejando de hacer algo “tedioso” o a mano que le hará ahorrar “algo” y por fin podrá enseñar a comité. Y esto lo sabe porque, la persona que “le vendió” tu producto, entendió su problema, le enseñó la solución y por eso sabe, que esto va a funcionar.
Ahora pregúntate, ¿está esto en el contrato?
No, seguramente no. Lo que sí tienes es tu documento: qué se ha vendido, por cuánto y con qué módulos. Lo que no llega es el para qué: qué esperaba conseguir, en cuánto tiempo y qué es lo que en su cabeza significa que esto ha salido bien.
Y aquí es donde nace la mayoría del churn que luego intentamos explicar con health scores, con reuniones de seguimiento y a veces, concesiones.
Porque dentro de un año, ese cliente no va a renovar contra el contrato, va renovar contra lo que se imaginó.Lo que cambió cuando sí lo supimos
Dos situaciones que viví, y que me cambiaron la forma de entender un buen handover.
La primera.
Cuando conseguimos que llegara a CS, el qué esperaba el cliente de verdad, dejamos de empezar “por lo de siempre”, por el primer paso que no aportaba tanto valor, que era una configuración a medida que se llevaba a cabo semanas antes de que el cliente viera nada.
En vez de eso, decidimos empezar por analizar qué desatascaba la operativa. En una semana ya tenía un insight, un primer resultado concreto que podía usar y enseñar. Además pasó algo que no esperaba: se agilizó el cobro de las facturas. Dos quick wins por el precio de uno.
Y es que tiene toda la lógica cuando lo piensas. Un cliente que todavía no ha visto nada tiene todos los incentivos para ir despacio con el pago, pero un cliente que ya ha obtenido algo útil, no, lo quiere todo y lo quiere ya porque ha visto el potencial. El time to value no es solo una métrica de adopción. También es una métrica de caja.
La segunda.
Esta fue la que me dejó claro que el handover es un mecanismo de detección de riesgo, no un trámite administrativo.
Al entender qué esperaba conseguir el cliente con el producto, CS pudo levantar la mano y decir algo incómodo: ese compromiso, con el equipo que teníamos en ese momento, no se podía asumir.
No se paró porque alguien tuviera un mal presentimiento. Se paró porque, por primera vez, quien tenía que ejecutarlo sabía qué se había prometido antes de que fuera tarde.
Y aquí está lo importante, que casi nadie ve: el problema no se habría quedado en esa cuenta, ya que comprometer al equipo con algo inasumible habría paralizado los proyectos de los demás clientes, con sus propios compromisos y sus propias penalizaciones. Aquella decisión no salvó una cuenta. Evitó un efecto dominó de deudas incumplidas.
Así que quédate con esto cuando tengas que crear tu Handover:
Un traspaso bien hecho no sirve solo para arrancar mejor, sirve para poder frenar a tiempo.
Por qué las plantillas de handover no lo resuelven
Lo diré claro: porque la mayoría de plantillas que he visto recogen lo mismo y en ninguna lo que se dijo en las reuniones y que casi nunca se cuentan en ningún documento:
- Qué problema venía a resolver. No el caso de uso genérico. El dolor concreto que le hizo firmar. “Están perdiendo dos días al mes cerrando el reporting” es útil. “Necesitan mejorar la eficiencia” no es nada.
- Qué se prometió exactamente. Incluyendo lo que se dijo de palabra en una reunión y no está en el contrato. Es lo que más duele y lo que menos se transfiere, porque dejarlo por escrito parece una confesión, pero no debería serlo: casi siempre esa promesa se hizo para desbloquear un cierre que había que cerrar. El problema no es que se prometiera, es que nadie más se enteró y no se sabe cómo solucionarlo.
- En qué plazo lo espera. El cliente casi siempre tiene una fecha en la cabeza, aunque no esté en ningún sitio. Un comité, un cierre de trimestre, una auditoría. Esa fecha determina si tu plan de onboarding es razonable o va a llegar tarde desde el primer día.
- Qué significa para él que esto funcione. Y quién dentro de su empresa tiene que quedar convencido. Porque muchas veces el que firma no es el que decide la renovación.
Y no empieza cuando se firma
Aquí está la parte que suele incomodar, y es la que de verdad cambia las cosas.
Si esa información no se recogió durante el proceso comercial, no se puede transferir después. Y no es mala voluntad de nadie: es que nadie definió que había que recogerla. A un comercial se le mide por cerrar, y si nunca se acuerda de que esas cuatro cosas forman parte del cierre, no van a estar.
Por eso el handover no se arregla montando una reunión de traspaso mejor o creando más campos en el documento. Se arregla decidiendo, antes, qué información tiene que capturarse durante la venta porque la postventa (KAM,CS, Ops,Soporte,…) la va a necesitar.
Y eso ya no es un tema de CS, o un problema de ventas, es un acuerdo entre varios equipos sobre qué se pregunta, dónde se guarda y quién responde de que esté, porque todos tenemos el objetivo común de hacer crecer la empresa. Sentaros, hablar y tratar el tema poniendo al cliente en el medio.
Cómo montarlo sin un proyecto de seis meses
Cuatro movimientos, y ninguno necesita herramienta nueva.
- Escribe la lista mínima. Las cuatro cosas de arriba, adaptadas a tu producto. Que quepan en media página. Una lista larga no se rellena, y una que no se rellena no existe.
- Ponle un dueño al traspaso, no solo a los datos. Alguien tiene que ser responsable de que el relevo ocurra, no solo de que la información esté. Si nadie lo es, el traspaso se convierte en un correo que se responde cuando se puede.
- Haz que el cliente lo valide. Este es el paso que casi nadie da y el que más devuelve. En la primera sesión, léele lo que has entendido que espera conseguir y en qué plazo. Dos cosas van a pasar: o te corrige, y acabas de evitarte tres meses de trabajo en la dirección equivocada, o te confirma, y ahora tienes un acuerdo compartido sobre qué es el éxito.
- Dale a Operaciones el derecho a frenar. De nada sirve detectar un compromiso inasumible si quien lo detecta no tiene forma de pararlo. Ese derecho hay que darlo explícitamente y decir en voz alta que usarlo es hacer bien el trabajo, no ser negativo. Si tu equipo cree que levantar la mano le va a costar caro, no la va a levantar, y el problema aparecerá igual, solo que más tarde y más caro.
Qué puedes hacer con esto
- Si eres KAM o llevas Ventas, esto no va contra ti. De hecho, eres quien más tiene que ganar. Y hay una parte que solo puedes aportar tú: dejar constancia de lo que se dijo de palabra. Esa promesa que hiciste para desbloquear el cierre, ese plazo que diste sin confirmarlo con nadie, esa funcionalidad que dijiste que estaba al caer.
No es un examen ni un control. Es que si no viaja, quien va a estar delante del cliente cuando lo reclame no vas a ser tú. Y hay una ventaja que suele pasar desapercibida: un cliente al que se le cumple lo que se le prometió renueva, se expande y te presenta a otros. La calidad de tu handover es la calidad de tus referencias dentro de un año.
Eso sí, esto no debería depender de tu memoria ni de tus ganas. Si tu empresa no ha definido qué se recoge, dónde vive y quién responde de que esté, el fallo no es tuyo. Tú puedes aportar el contexto, porque eres el único que estaba en esa sala. Pero que llegue al otro lado es cosa del sistema.
-
Si eres el CSM, empieza por documentar lo que te falta. Cada vez que tengas que reconstruir a mano qué se prometió, anótalo. Al cabo de un mes tienes un patrón, y un patrón es una conversación distinta a una queja suelta.
-
Si estás en Soporte, probablemente eres el equipo al que menos le llega el traspaso y el que antes ve las consecuencias. Recibes tickets sin saber qué esperaba conseguir ese cliente ni qué se le prometió, así que resuelves incidencias sueltas sin poder valorar cuáles son señales de algo mayor. Dos cosas cambian mucho aquí.
-
Pedir el contexto mínimo de las cuentas que más pesan: qué compraron, para qué y qué es crítico para ellos. No para tratarlos distinto, sino para saber cuándo un ticket normal en realidad está tocando lo único que a ese cliente le importaba.
-
Tu información tiene que viajar de vuelta. Un cliente que abre tres veces el mismo tipo de incidencia sobre el proceso que vino a resolver no es un problema de soporte. Es un aviso de renovación con meses de antelación, y muchas veces nadie más lo está viendo. Fíjate en que esto no es una cadena, es un círculo: lo que Soporte ve tiene que volver a Ventas en forma de qué prometer y qué no.
-
Si lideras el equipo, coge las tres últimas cuentas que arrancaron mal y busca qué información no viajó. No para señalar a nadie, sino para construir la lista mínima con casos reales encima de la mesa. Es mucho más fácil acordar un cambio con tres ejemplos que con una teoría.
-
Si eres COO o CEO, esto no es papeleo entre departamentos. Es el punto donde tu empresa decide si va a cumplir lo que ha vendido. Y la pregunta que yo haría en el próximo comité es simple: de las cuentas que arrancaron mal el último trimestre, ¿en cuántas el problema apareció después de la firma, y en cuántas ya estaba ahí antes y nadie lo vio?
Porque el coste de un handover roto no se paga en el onboarding, se paga en la renovación que no llega, en la factura que se retrasa, y a veces en un compromiso que nunca debiste aceptar.¿Qué es lo que más veces has tenido que reconstruir a mano porque no llegó en el traspaso? Cuéntamelo, tengo curiosidad por ver si se repite el patrón.
Artículos relacionados