Abres tu HubSpot y el pipeline de Deals termina en Closed Won. Después de esa etapa, no pasa nada. El vendedor cerró, cobró su comisión, y el proyecto desapareció del CRM. Si quieres saber cómo va la ejecución, le escribes al PM por WhatsApp. Si quieres saber el margen real, abres un Excel que alguien actualiza los viernes. Eso no es un CRM — es una libreta de contactos con pipeline.
Este es el patrón que se repite en casi todas las empresas de servicios profesionales en Chile, Colombia, Argentina y la región: implementaron HubSpot como si fueran una empresa de producto, y ahora tienen una herramienta que no refleja cómo funciona su negocio. El problema no es HubSpot. El problema es el modelo de objetos con el que lo configuraron.
HubSpot nació pensando en empresas que venden producto repetible: SaaS, e-commerce, suscripciones. Ahí el flujo es lineal — lead, oportunidad, cierre, cliente. El producto existe antes de la venta, la entrega es estándar, y el margen se calcula a nivel de SKU.
En una empresa que vende proyectos nada de eso aplica. El producto no existe hasta que se construye. La preventa requiere trabajo operativo real — levantamiento de información, diseño de propuesta, validación técnica. La entrega puede tomar meses y atravesar múltiples áreas. El margen depende de costos que se acumulan durante la ejecución, no de un precio de catálogo.
Ventas cierra un deal de USD 80,000 con una consultora. Operaciones recibe el handover por correo. Tres meses después, el director financiero pregunta cuál fue el margen real. Nadie sabe. Los costos están en un Excel del PM, las horas en otro Excel del equipo, y las facturas a proveedores en el ERP. Reconstruir el dato toma una semana.
Eso no es un problema de disciplina. Es un problema de arquitectura. El CRM no tiene los objetos necesarios para capturar esa realidad.
Un modelo de objetos en HubSpot para servicios profesionales funciona cuando seis piezas están bien conectadas: contactos, empresas, negocios, tickets, proyectos y facturas. Cada una tiene un rol específico. Ninguna se puede saltar sin pagar el costo después.
El contacto no es solo un nombre y un correo. Es el repositorio de todo lo que tu equipo sabe sobre esa persona: en qué etapa de decisión está, qué piensa de tu empresa, qué dolores tiene, qué objetivos persigue, cuál es su relación con el comercial que lo atiende.
La prueba ácida: cualquier persona del equipo debería poder retomar la conversación con cualquier contacto después de leer el CRM, sin pedirle un briefing verbal a nadie. Si tu director comercial se va de vacaciones y nadie puede continuar sus conversaciones sin llamarlo, tu modelo de contactos está roto.
La empresa es donde vive todo lo permanente: fit con tu propuesta de valor, señales de venta, proyectos históricos, facturas, MRR si aplica, competidores con los que estás peleando ese logo, probabilidad de churn.
Aquí es donde la mayoría comete el primer error grave: tratan a la empresa como un campo administrativo del deal. La empresa es la unidad de análisis estratégica. Es donde respondes preguntas como ¿cuánto nos ha dejado este cliente en tres años? o ¿qué tipos de proyectos hemos hecho con esta cuenta?.
Aquí es donde más empresas se rompen. El reflejo natural es crear un solo negocio por cliente y meter ahí todo lo que pasa. Está mal.
Una empresa puede tener varios negocios activos al mismo tiempo. Una consultora de transformación digital en Bogotá puede estar hablando de un proyecto de datos con el área de marketing, de una iniciativa de IA con dirección general, y de una integración de ERP con tecnología — todo en la misma cuenta cliente. Adentro del cliente esos proyectos viven en áreas distintas, con presupuestos distintos, con decisores distintos.
Si metes los tres en un solo deal, pierdes la visibilidad real. No sabes qué pipeline tienes con esa cuenta. No sabes qué deal está bloqueado y por qué. Los negocios deben reflejar la realidad operativa del cliente, no simplificarla por comodidad del CRM.
En el modelo correcto, el pipeline de negocios tiene dos mitades. La preventa — generación de propuesta, diseño, presentación, negociación. Y la postventa — In Progress, mantenimiento, ganado cerrado.
Cuando el cliente firma, el negocio no desaparece. Pasa a In Progress. El vendedor sigue viendo ese deal en su tablero. Puede abrirlo y ver en tiempo real cómo va la ejecución, qué se ha facturado, qué incidentes hay. Eso elimina la pregunta más común en empresas de servicios: ¿cómo va el proyecto del cliente X?.
Aquí es donde casi todas las implementaciones genéricas fallan. Los tickets en HubSpot se venden como herramienta de soporte al cliente. Para servicios profesionales, los tickets son otra cosa: son la unidad de trabajo interna de cada equipo operativo.
Cada equipo tiene su propio pipeline de tickets con sus propios KPIs y tiempos de respuesta. Algunos ejemplos de tickets de preventa:
Un deal puede cerrarse con 3 tickets. Otro deal del mismo tamaño puede necesitar 12. Ese dato queda registrado. Ahora puedes responder con precisión cuánto trabajo de preventa requirió cada negocio y comparar entre tipos de cliente, tamaños de deal o verticales.
El proyecto es un objeto distinto al negocio. Es donde vive todo lo de la ejecución post-cierre: costos acumulados, progreso, documentación entregable, quejas del cliente, incidentes, personas asignadas, pausas, cambios de alcance.
Un negocio puede tener varios proyectos. Volviendo al ejemplo de la consultora en Bogotá: el deal de transformación digital puede materializarse en tres proyectos distintos — uno de datos, uno de IA, uno de integración — cada uno con su PM, su equipo, su cronograma. Separarlos en el CRM no es burocracia. Es la única forma de tener visibilidad real de la ejecución.
Este es el objeto que falta en el 90% de las implementaciones que reviso. Las facturas — tanto las que cobras al cliente como las que pagas a proveedores y subcontratistas — viven en un objeto personalizado dentro de HubSpot.
No necesitas replicar tu ERP. Necesitas registrar: proveedor o cliente, monto, fecha, negocio asociado, proyecto asociado. Si tu empresa usa SAP, Oracle, Dynamics u Odoo, la integración por el ID del negocio es directa — un dato consistente en ambos sistemas basta para que la asociación sea automática.
Sobre el objeto negocio creas una propiedad rollup que suma todas las facturas entrantes y resta todas las salientes. Eso te da el margen real del deal, en tiempo real, sin abrir Excel y sin pedirle nada a finanzas.
El modelo solo funciona cuando los objetos se hablan entre sí. Veámoslo con un caso concreto: una empresa de software en Santiago vende una implementación de USD 120,000 a un retail argentino.
El contacto inicial entra por la web. Se asocia a la empresa cliente. Se crea un negocio en etapa de calificación. Durante la preventa, el equipo genera cinco tickets: levantamiento, demo técnica, diseño de solución, propuesta y negociación. Cada uno con su responsable y su tiempo de cierre.
Cuando el cliente firma, el negocio pasa a In Progress. Se dispara automáticamente la creación del proyecto y se programa la reunión de handover. El PM ya tiene acceso a todo lo trabajado en preventa — no recibe un brief verbal, recibe la documentación completa.
Durante los seis meses de proyecto, el equipo registra horas, factura hitos al cliente y registra pagos a tres subcontratistas. Cada factura se asocia al proyecto y al negocio. El rollup sobre el negocio muestra el margen actualizado todos los días.
El director comercial abre el deal y ve en una sola pantalla: estado del proyecto, incidentes abiertos, monto facturado, monto pendiente, margen actual. Si el margen empieza a deteriorarse por subcontrataciones imprevistas, lo ve antes que finanzas. Si hay un incidente crítico que puede afectar la renovación, lo ve antes que el cliente le escriba.
Si reconoces tres o más de estas situaciones en tu operación, el problema no es de disciplina del equipo. Es estructural:
Con el modelo de objetos correctamente diseñado para servicios profesionales, el CRM deja de ser una libreta de contactos sofisticada y se vuelve la versión digital real de tu operación. Ventas y operaciones trabajan en el mismo espacio. El margen es visible en tiempo real. Cada proyecto histórico se vuelve data que el equipo puede consultar para estimar el siguiente. Y cuando llegue el momento de sumar agentes de IA sobre tu operación — que va a llegar — vas a tener data estructurada de verdad, no un Excel que la IA va a inventar a partir de.
Diseñar este modelo no es algo que se descubre durante la implementación. Se mapea antes, se valida con la operación real, se aprueba con el cliente, y recién entonces se construye en HubSpot. Si quieres ver cómo se ve este modelo aplicado a una empresa que vende proyectos como la tuya, aquí está la arquitectura completa que implementamos.