5 promesas comerciales que operaciones nunca puede cumplir

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.

Por qué este patrón es estructural, no de actitud

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.

El área comercial decide con información que no existe

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.

El parche que la mayoría intenta y por qué falla

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é.

Las 5 promesas comerciales que destruyen rentabilidad

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.

1. "Lo entregamos en X semanas" — el timeline negociado en el almuerzo

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ó.

2. "Eso lo incluimos sin costo" — el alcance que crece en la última llamada

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ó.

3. "Te asignamos al equipo que viste en la propuesta"

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.

4. "La integración con tu ERP es estándar"

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.

5. "Hacemos los ajustes que necesites durante la implementación"

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.

Un mejor modelo: preventa estructurada en el mismo sistema que post-venta

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.

Preventa como tickets, no como conversaciones sueltas

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.

El handover deja de ser una reunión y se vuelve un registro

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.

Visibilidad bidireccional después del cierre

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.

Señales tempranas de que el traspaso está roto en tu empresa

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:

• Los kickoffs de proyecto empiezan con operaciones aclarando "lo que el vendedor en realidad quiso decir" — y el cliente pone cara de sorpresa.
• El alcance del proyecto vive en un PDF de propuesta, no en el CRM, y cada quien tiene su propia versión guardada en su computador.
• Los vendedores no saben qué pasó con los proyectos que cerraron hace seis meses, y operaciones no tiene un registro estructurado de qué se prometió antes del cierre.
• Las quejas del cliente sobre el alcance terminan en cadenas de correos buscando "quién dijo qué" — y nadie tiene una respuesta clara con fecha y firma.
• El margen real de tus proyectos se calcula en Excel después de cerrados, no en tiempo real dentro del sistema donde vive el deal.

Lo que cambia cuando las promesas comerciales se hacen sobre data real

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.