El proyecto pierde plata antes de la reunión de kickoff. El protocolo de traspaso ventas-operaciones que tienes hoy —si es que existe— es una llamada de 45 minutos donde el comercial cuenta lo que recuerda, el PM toma notas en un cuaderno, y nadie firma nada.
Tres semanas después, el cliente reclama un entregable que el vendedor prometió en un correo que nadie operativo vio. El alcance se expande sin que el precio cambie. El margen estimado del 35% se evapora a 12%. Y en la junta del trimestre, alguien pregunta por qué los proyectos están costando más de lo presupuestado.
La respuesta no es "mejor comunicación". La respuesta es un protocolo documentado, ejecutable, y conectado al CRM. Eso es lo que cubre este artículo.
El diagnóstico habitual es que ventas y operaciones "no se hablan". Es falso. Se hablan todo el día —por WhatsApp, por correo, en pasillo. El problema no es la cantidad de comunicación; es que ninguna de esas conversaciones queda registrada en un lugar donde el equipo operativo pueda buscarla cuando arranque el proyecto.
Cuando un comercial cierra un deal en una consultora de Bogotá, un implementador de SAP en Santiago, o una agencia tecnológica en Buenos Aires, lo que existe es: una propuesta firmada (que rara vez tiene el detalle operativo), un correo de confirmación, y la memoria del vendedor. Operaciones reconstruye el contexto a partir de fragmentos.
Cada hora que el PM gasta reconstruyendo el contexto del deal es una hora no facturable. Si el proyecto vendido tiene 400 horas presupuestadas y el PM gasta 20 entendiendo qué se vendió, ya quemó el 5% del presupuesto antes de empezar.
Multiplica eso por cada proyecto del año. Esa es la cifra real que el protocolo de traspaso ventas-operaciones existe para proteger.
La solución que todo mundo intenta primero es la "reunión de handover". Vendedor, PM, y a veces el cliente. Se agenda cuando el deal cierra, dura una hora, y se asume que con eso el contexto queda transferido.
Falla por tres razones concretas:
La reunión de handover, sin un sistema que la respalde, es teatro corporativo. Cumple con un ritual pero no transfiere información operativa real.
El cambio mental más importante es este: el handover no es un evento, es la culminación de un proceso que empezó cuando el comercial tuvo la primera conversación con el prospecto. Si el proceso de preventa está bien estructurado, el traspaso es trivial. Si no lo está, ninguna reunión lo va a arreglar.
Esto implica un rediseño del proceso comercial: cada interacción de preventa genera un artefacto operativo. No un correo, no una nota mental. Un registro estructurado en el CRM que opera como input para el proyecto.
En la práctica, esto se ve como una serie de tickets de preventa dentro del CRM, cada uno con un deliverable concreto:
Cuando el deal cierra, el handover no es transferir información que solo existe en la cabeza del vendedor. Es revisar artefactos que el PM ya pudo leer.
Este es el paso que casi nadie tiene y que más protege la rentabilidad. Antes de que el comercial mande la propuesta al cliente, alguien de operaciones —el PM que potencialmente va a ejecutar, o un líder técnico— firma que lo prometido es ejecutable en el tiempo y presupuesto estipulados.
Eso elimina el 80% de las sorpresas post-cierre. El comercial no puede prometer lo que operaciones no validó. Y cuando opera, ya hay un PM que conoce el contexto desde antes del cierre.
Un protocolo serio no es un documento de Word con buenas intenciones. Es un flujo dentro del CRM con etapas, responsables, deliverables y disparadores automáticos. Hablemos de cada componente.
El pipeline de deals no debería tener solo etapas comerciales ("calificación", "propuesta", "negociación", "cerrado"). Debe tener etapas que reflejen el trabajo operativo de preventa: "levantamiento", "blueprint", "validación interna", "propuesta enviada", "cierre".
Cada etapa avanza solo cuando el ticket de preventa correspondiente está completado. No es opcional. Si no hay blueprint validado, el deal no puede pasar a "propuesta enviada".
Cuando el deal entra en la etapa de cierre, el CRM dispara automáticamente: notificación al PM asignado, creación del proyecto en el sistema, copia de todos los tickets de preventa al expediente del proyecto, y agendamiento de la reunión de briefing.
La reunión de briefing no es para transferir información —el PM ya la leyó. Es para resolver dudas específicas y confirmar el plan de arranque. Dura 30 minutos, no 90.
El protocolo no termina en el handover. El vendedor sigue teniendo acceso al estado del proyecto: salud general, hitos cumplidos, incidentes críticos, facturación al día. Esto no es para que microgestione operaciones —es para que cuando el cliente lo llame tres semanas después preguntando algo, no tenga que escribirle al PM.
Y operaciones tiene visibilidad de qué prometió el comercial, en qué reunión, y con qué supuestos. Cuando aparece la primera ambigüedad, hay un registro estructurado que la resuelve sin reuniones de emergencia.
Si reconoces dos o más de estas señales, el problema no es la gente —es el sistema:
Cada una de estas señales tiene un costo medible. Súmalas para tu operación y vas a entender por qué un protocolo serio paga su implementación en menos de un trimestre.
Sin un CRM correctamente configurado, ningún protocolo de traspaso ventas-operaciones funciona. Las hojas de Excel, los Google Docs compartidos y los grupos de WhatsApp pueden parecer suficientes para un equipo de 5 personas, pero se rompen apenas la empresa tiene 3 vendedores y 5 PMs trabajando en paralelo.
El CRM no es un repositorio de contactos. Es el sistema operativo del negocio: donde viven los deals, los proyectos, los tickets de preventa, las facturas, los incidentes. Cuando todo está en el mismo lugar, conectado por relaciones explícitas, el traspaso deja de ser un evento riesgoso y se vuelve una transición fluida.
Porque están configuradas como si la empresa vendiera producto, no proyectos. Tienen pipeline de deals pero no objetos para tickets de preventa, ni para proyectos con sus propios estados, ni para facturas asociadas que permitan ver el margen en tiempo real.
Una implementación pensada para empresas que venden intangibles de alto valor —consultoría, software, servicios profesionales— se ve completamente diferente. Y es la única que sostiene un protocolo de traspaso ventas-operaciones de verdad.
Cuando el protocolo opera, el margen del proyecto se parece al margen prometido en la propuesta. Los PMs llegan al kickoff con contexto completo. Los vendedores dejan de ser el cuello de botella de información post-cierre. Y la empresa puede escalar el número de proyectos simultáneos sin que la calidad operativa colapse —porque el conocimiento vive en el sistema, no en las cabezas de tres personas clave.
Si quieres ver cómo se ve un CRM configurado específicamente para sostener este tipo de protocolo en una empresa que vende proyectos, acá está el modelo que implementamos —con los objetos, pipelines y automatizaciones que hacen que el traspaso deje de ser el punto donde se pierde la rentabilidad.