El director de operaciones lo ve venir desde el correo de "ganamos el proyecto". Antes de abrir la propuesta, ya sabe que las promesas comerciales que vienen adentro incluyen un timeline imposible, un alcance inflado y una integración que el vendedor describió como "estándar" sin haberla revisado con nadie técnico.
Esa propuesta firmada es una bomba de tiempo. Y el ciclo se repite porque los compromisos que destruyen proyectos no son errores aislados — son patrones predecibles que la mayoría de las empresas de servicios profesionales nunca logra cortar.
La narrativa fácil es que el vendedor "promete de más" porque tiene comisión. Esa explicación es cómoda pero incompleta. El vendedor promete lo que su sistema le permite prometer.
Si tu CRM no muestra la capacidad real del equipo de delivery, si las propuestas se construyen en Word sin conexión a tickets de preventa, si nadie de operaciones firma el alcance antes del cierre — el vendedor está operando a ciegas. Su intuición es lo único que tiene a mano.
Estás pidiéndole al equipo comercial que tome decisiones técnicas sin data estructurada. Después te sorprende que las promesas no aterricen en la ejecución.
El problema no es ético. Es arquitectónico. Y mientras no cambies la arquitectura, podés rotar tres veces al equipo de ventas y el patrón se va a repetir con caras nuevas.
La respuesta convencional es meter más reuniones. Comité de revisión de propuestas, sign-off de operaciones antes de enviar, llamada de handover de una hora cuando se cierra el deal.
El resultado predecible: ventas siente que operaciones es un obstáculo burocrático, operaciones siente que ventas no escucha, y las reuniones se vuelven teatro. Al cuarto mes, los vendedores aprenden qué decir para que el comité apruebe rápido, no qué validar para que el proyecto sea ejecutable.
El parche falla porque ataca el síntoma. La fricción entre áreas no se resuelve con más reuniones — se resuelve cuando ambas áreas trabajan sobre la misma data en tiempo real, dentro del mismo sistema, con el mismo registro de qué se prometió y por qué.
Vamos a las promesas concretas. Son las que aparecen en cada empresa de servicios profesionales de Chile a Argentina, sin importar el tamaño o el rubro.
El cliente pregunta cuánto tarda. El vendedor, sin abrir el CRM, responde con un número que suena bien. Esa fecha entra a la propuesta sin haber pasado por nadie que ejecute.
Lo que operaciones recibe: un compromiso firmado para una fecha que no consideró la disponibilidad real del equipo senior, las dependencias del cliente (información que no entrega a tiempo, accesos que demoran), ni los proyectos ya comprometidos en el pipeline.
El daño es doble. El proyecto arranca tarde porque hay que renegociar el plan, y el equipo de operaciones empieza la relación con el cliente disculpándose por algo que no prometió.
En la reunión final antes del cierre, el cliente pide algo adicional. El vendedor, con el deal a punto de caerse, dice que sí. No lo documenta en el CRM, no lo agrega al alcance formal, solo lo menciona de pasada en un correo.
Operaciones se entera tres semanas después del kickoff, cuando el cliente reclama el módulo extra que "el vendedor me prometió". El margen ya se evaporó y nadie tiene un registro claro de qué se acordó.
La propuesta muestra los CVs del arquitecto senior, la PM con diez años de experiencia, el desarrollador que lideró el proyecto similar. El cliente compra ese equipo. La realidad: ese equipo está asignado a otros tres proyectos.
Operaciones tiene que rearmar el squad con los recursos disponibles. El cliente nota la diferencia en la primera reunión y la confianza se rompe antes de la primera entrega formal.
El vendedor sabe que su empresa "ya hizo integraciones con SAP" o con Oracle, Dynamics, Odoo. De ahí salta a decirle al cliente que conectar con su instancia específica es trivial. Nadie técnico validó esa instancia específica.
Operaciones descubre que el cliente tiene una versión personalizada con módulos custom, sin APIs documentadas, mantenida por un proveedor externo que tarda dos semanas en responder un correo. La "integración estándar" se convierte en semanas de trabajo no presupuestado.
Esta es la más insidiosa. El vendedor cierra el deal diciendo que el equipo es "flexible" y que se adapta a lo que el cliente vaya pidiendo en el camino. No define qué entra en el alcance original ni qué constituye un cambio.
Operaciones recibe un proyecto sin frontera. Cada solicitud del cliente es interpretada como "algo que el vendedor ya dijo que entraba", y el equipo termina ejecutando dos proyectos por el precio de uno.
La forma de cortar este patrón no es disciplinar al área comercial. Es darle al vendedor un sistema donde no pueda prometer lo que operaciones no puede ejecutar.
El modelo que funciona tiene tres componentes. Primero, la preventa se ejecuta como tickets de trabajo dentro del CRM — levantamiento de información, diseño de blueprint, creación de propuesta. Cada ticket tiene responsable y delivery documentado.
Segundo, antes de pasar el negocio a etapa de cierre, alguien de operaciones tiene que firmar digitalmente el ticket de blueprint. No es una reunión — es un campo del registro que cambia de estado. Si no está firmado, el deal no avanza de fase.
Cuando el deal se gana, la transferencia a operaciones no es una llamada de una hora donde el vendedor explica de memoria lo que prometió. Es la apertura del proyecto con todos los tickets de preventa asociados, los deliveries firmados, y el alcance documentado dentro del registro.
El PM que recibe el proyecto no depende de la memoria del vendedor. Abre el negocio en el CRM y ve exactamente qué se levantó, qué se diseñó, qué firmó el cliente y qué quedó fuera. La caja negra desaparece.
Una vez iniciado el proyecto, el vendedor no desaparece del CRM. Puede abrir el deal y ver el estado del proyecto, los incidentes críticos, los fees cobrados y los pendientes — sin preguntarle a operaciones por WhatsApp ni agendar otra reunión.
Esto cambia el incentivo de raíz. El vendedor que ve cómo van sus proyectos cerrados aprende qué promesas duelen en la ejecución. Sin esa visibilidad, sigue prometiendo lo mismo porque nunca paga el costo de la promesa.
Antes de rediseñar el modelo, vale hacer un diagnóstico honesto. Si reconocés tres o más de las siguientes señales, el problema ya está costándote márgenes significativos cada trimestre:
Cuando el vendedor cierra un deal sobre un blueprint firmado por operaciones, con tickets de preventa que documentan cada deliverable y con un alcance que existe como registro y no como recuerdo, el proyecto arranca con cero ambigüedad. El kickoff es corto, el equipo entra a ejecutar lo que ya aprobó el cliente, y la rentabilidad se defiende sola.
Si querés ver cómo se ve esta arquitectura cuando está implementada de punta a punta — preventa, handover, ejecución y visibilidad financiera dentro del mismo sistema — acá está el modelo que usamos para empresas que venden proyectos. No es teoría: es el blueprint que ya está corriendo en consultoras, empresas de software y firmas de servicios profesionales en la región.