¿Por qué fracasan tantas implementaciones?
El patrón se repite con una consistencia incómoda: se elige la herramienta, se configura con las etapas que traía por defecto, se importan los contactos, se capacita al equipo en dónde hacer clic, y a los tres meses la información importante vuelve a moverse por chat y hojas de cálculo.
La causa no es la plataforma. Es que se configuró antes de levantar el proceso comercial, así que el sistema le pide al equipo más trabajo del que le devuelve. Y cuando un vendedor tiene que elegir entre cerrar un negocio y actualizar una ficha, siempre elige cerrar el negocio.
¿Cómo se levanta el proceso comercial real?
Preguntando por hechos, no por etapas. La conversación útil no es «¿cuáles son tus fases de venta?» sino «cuéntame los últimos cinco negocios que cerraste, uno por uno, desde el primer contacto».
De esos relatos salen las etapas reales, que casi nunca coinciden con el diagrama que existe en la presentación corporativa. Una etapa bien definida describe un hecho verificable —«propuesta enviada», «diagnóstico agendado»— y no un estado de ánimo del vendedor, como «interesado» o «en proceso».
La prueba de que el levantamiento funcionó: preguntas a dos vendedores qué significa una etapa y responden lo mismo.
¿Cómo se elige la herramienta?
Con tres preguntas, en este orden, y la comparativa de funcionalidades va al final.
- ¿Cómo vende tu equipo hoy? Si no puedes describirlo en etapas con criterios verificables, ninguna herramienta va a ayudarte todavía.
- ¿Quién va a administrar el sistema? Si la respuesta es «nadie en particular», descarta la opción más compleja sin discutirla.
- ¿Qué tiene que estar conectado? Si el CRM debe hablar con un ERP o con facturación, esa integración pesa más que cualquier funcionalidad del comparativo.
A grandes rasgos: HubSpot cuando marketing y ventas trabajan juntos y necesitas adopción rápida sin equipo técnico; Zoho cuando el presupuesto manda; Salesforce cuando los procesos son genuinamente complejos y hay quien administre la plataforma.
¿Cómo se presupuesta sin sorpresas?
Separando dos partidas que responden a lógicas distintas. La licencia es pública y predecible: se consulta en una página de precios. La implementación no es pública porque depende de tu operación.
Seis variables mueven el número, en orden aproximado de impacto: integraciones, calidad de los datos de origen, número de procesos comerciales distintos, personalización, migración de historial, y usuarios a capacitar.
Como referencia de esfuerzo: un pipeline sin integraciones y con datos limpios se mide en semanas; varios pipelines con una integración y migración, en uno a tres meses; múltiples integraciones con objetos personalizados y varias unidades de negocio, en tres meses o más.
¿Qué costos se olvidan siempre?
| Costo olvidado | Cuándo aparece |
|---|---|
| Limpieza de datos previa | Al abrir la base, no al cotizar |
| Tiempo del propio equipo | Sesiones de levantamiento y validación: horas que no se vende |
| Soporte posterior | Un CRM vivo cambia: procesos nuevos, campos que sobran |
| Crecimiento de la licencia | Cada mes, si la estructura de usuarios se planificó mal |
Son los que producen la sensación de que el proyecto «se salió del presupuesto» cuando en realidad nunca estuvo dentro.
¿Qué se configura primero?
El pipeline principal y nada más. La tentación de configurarlo todo antes de lanzar es fuerte y casi siempre es un error: alarga el proyecto, retrasa el aprendizaje y produce automatizaciones sobre supuestos que aún no se han probado.
El orden que funciona: pipeline principal y propiedades mínimas → adopción del equipo durante unas semanas → automatizaciones sobre lo que ya se usa → integraciones. Cada fase revela problemas que la anterior no dejaba ver, y descubrirlos de a uno es mucho más barato.
¿Qué campos deben ser obligatorios?
Los mínimos, y cada uno debe ganarse su lugar. Cuando un campo es obligatorio pero no aporta valor a quien lo llena, el equipo aprende a burlarlo: aparecen «n/a», «1» y «pendiente» — y a partir de ahí el dato deja de ser confiable para todos.
Una regla práctica: si nadie va a filtrar, segmentar o reportar por ese campo en los próximos tres meses, no debería ser obligatorio todavía.
¿Qué hay que resolver antes de migrar datos?
Cuatro cosas, y la primera es la que más se subestima.
- Limpiar antes, no después. Si migras duplicados, tendrás el problema en dos sistemas.
- Decidir qué historial se trae. Migrar todo encarece sin aportar; el historial antiguo rara vez se consulta. Un corte por antigüedad y el resto archivado fuera del CRM.
- Normalizar los valores de selección. «Bogotá», «bogota» y «BOG» son tres valores distintos para cualquier sistema.
- Inventariar lo que consume datos del CRM. Integraciones, reportes y también las hojas de cálculo que alguien mantiene a mano. Estas últimas son las que rompen sin avisar.
¿Cómo se asegura la adopción?
Diseñando para que el sistema devuelva más de lo que pide. Tres palancas concretas:
Que el pipeline describa la realidad. Un vendedor adopta un sistema que refleja cómo trabaja y esquiva uno que le pide traducir su realidad a categorías ajenas.
Que automatice algo desde el primer día. Si el CRM le ahorra escribir el mismo correo de seguimiento veinte veces, se gana el derecho a pedirle que actualice una ficha.
Que los reportes cambien decisiones visibles. Cuando el equipo ve que la reunión semanal se decide con datos del CRM, mantenerlo actualizado deja de ser burocracia y pasa a ser influencia.
¿Cómo se sabe si la implementación funcionó?
No por el número de usuarios activos, que es fácil de inflar. Tres señales honestas: qué porcentaje de negocios abiertos tiene fecha estimada de cierre, dónde ocurre el seguimiento real de un negocio importante, y si alguna decisión comercial concreta salió de un reporte del CRM en el último mes.
Si el seguimiento importante sigue viviendo en un grupo de chat, el CRM está funcionando como archivo muerto, sin importar cuántos usuarios entren cada día.
¿Y si ya tengo un CRM que no funciona?
Casi nunca la primera medida es cambiar de herramienta. La mayoría de las implementaciones fallidas fallan por configuración y proceso, y migrar sin corregir eso reproduce el mismo problema en otra plataforma, con el costo añadido de la migración.
El camino que funciona es volver al levantamiento y reconfigurar sobre esa base. Si además vas a migrar, aprovecha: una migración es la única ventana barata para rediseñar, porque es la única vez en que todo el mundo acepta que las cosas van a cambiar.