Una escena que se repite demasiado
En proyectos de Salesforce hay escenas que se repiten con una regularidad casi incómoda. La implementación técnica salió bien: los flujos funcionan, los reportes están armados, el sandbox se probó, todo el mundo firmó el go-live. Seis meses después, un gerente comercial nos escribe con una variación de la misma frase: "tenemos Salesforce, pagamos las licencias, pero nadie realmente lo usa".
Vale la pena decirlo sin vueltas: cuando eso pasa, casi nunca es un problema de que "la gente es resistente al cambio" o de que "hay que capacitar más". Casi siempre se trata de un problema de diseño del sistema y de cómo se gestionó el cambio — dos cosas que sí se pueden corregir, y que Salesforce trata como disciplina propia dentro de su plataforma de formación, Trailhead, no como un tema aparte de "soft skills".
El error de fondo: tratar la adopción como un problema técnico
Cuando un proyecto de Salesforce se planifica, el foco suele estar dirigido a lo técnico: qué objetos crear, qué automatizaciones armar, qué integraciones conectar. La adopción queda postergada a una capacitación de dos horas en la última semana antes del lanzamiento, con la lógica implícita de que si el sistema funciona bien, la gente lo va a usar.
Esa lógica es exactamente al revés de lo que dice el propio material de formación de Salesforce sobre gestión del cambio. Trailhead plantea un modelo bastante simple para entender la adopción: los usuarios adoptan una herramienta cuando perciben que es fácil de usar y perciben que les resuelve algo que a ellos les importa. Si falta cualquiera de las dos condiciones — si es fácil pero no les sirve para nada que les importe, o si les serviría pero es una tortura de usar — la adopción no sucede, sin importar cuánta capacitación se dé.
La pregunta correcta: si tu equipo de ventas no usa Salesforce, la primera pregunta no debería ser "¿cómo los capacito mejor?" sino "¿este sistema, tal como está configurado hoy, les resuelve algo que a ellos les importa, o solo le sirve a la gerencia para tener reportes?".
La pregunta que casi nadie se hace antes de implementar
En la mayoría de los proyectos que heredamos de otras implementaciones fallidas encontramos el mismo patrón: el CRM se diseñó pensando en lo que la dirección comercial necesitaba ver (pipeline, forecast, conversión por etapa), pero nadie se sentó a preguntarle al vendedor qué le hace perder tiempo hoy y si Salesforce se lo va a resolver o se lo va a agregar.
Un vendedor que tiene que cargar la misma información en Salesforce y después de nuevo en una planilla para su propio seguimiento no va a adoptar el sistema por más lindo que sea el dashboard. Un vendedor al que Salesforce le automatiza el registro de llamadas, le sugiere el próximo paso y le ahorra tiempo real en su día, lo va a usar sin que nadie se lo pida. La diferencia entre esos dos escenarios no es de personalidad de los usuarios, sino de diseño.
Lo que sí funciona: encontrar a los que ya están convencidos
Uno de los conceptos que más repetimos en proyectos de Zarasa viene directamente de los materiales de formación de Salesforce sobre gestión del cambio: identificar usuarios avanzados o "champions" desde temprano, y apoyarse en ellos en lugar de depender únicamente de un anuncio de gerencia o de una capacitación formal. La razón tiene sentido si se piensa bien: las personas se guían mucho más por lo que ven hacer a sus pares — qué se considera normal, aceptable o efectivo dentro del equipo — que por una directiva que viene de arriba.
En la práctica, esto significa elegir a dos o tres vendedores (no necesariamente los que más venden, sino los que tienen más ascendencia informal sobre el resto) e involucrarlos antes del lanzamiento general: que prueben el sistema, que den feedback real, que encuentren un caso de uso donde Salesforce les ahorre tiempo de verdad. Cuando esos usuarios muestran una victoria concreta y visible al resto del equipo, el resto empieza a copiar el comportamiento sin que nadie tenga que convencerlos con un discurso.
El rol del liderazgo no es "aprobar el proyecto", es usarlo primero
Otro punto que aparece con fuerza en el material de Salesforce sobre liderazgo del cambio organizacional es algo bastante directo: si el liderazgo no está dispuesto a cambiar su propio comportamiento, es difícil pedirle al resto que lo haga.
Un caso que se cita habitualmente en esos materiales es el de un ejecutivo que anunció que ya no iba a revisar reportes de ventas en planillas o presentaciones: solo lo que estuviera cargado en el CRM. Ese tipo de decisión, tomada por quien lidera el equipo, cambia el cálculo de todos los demás. Si el gerente solo mira lo que está en Salesforce, cargar la información deja de ser opcional.
Esta idea implica que el liderazgo tiene que sacrificar algo — tiempo, comodidad, la costumbre de pedir un reporte armado a mano en lugar de mirar el dashboard tal como está — para que el resto del equipo entienda que el cambio va en serio.
Datos limpios: la condición que nadie quiere resolver primero
Hay un último factor que combina lo técnico con lo humano: la calidad de los datos. Un sistema con contactos duplicados, campos vacíos y oportunidades desactualizadas no solo produce reportes poco confiables: también le enseña al usuario, de forma silenciosa, que cargar información ahí "no importa tanto", porque total ya está todo desordenado.
Es un círculo que se retroalimenta: datos malos generan desconfianza, desconfianza genera menos carga de información, y menos carga de información empeora los datos. Romper ese círculo casi siempre requiere un esfuerzo puntual de limpieza y gobernanza de datos al principio del proyecto — no como una tarea de IT aislada, sino como parte visible del lanzamiento — para que el equipo vea un sistema confiable desde el primer día y no uno que van a tener que "perdonar" mientras se arregla solo con el tiempo.
Diagnóstico rápido: 4 preguntas antes de culpar a la capacitación
- 1. ¿Qué le resuelve el sistema a la persona que carga datos todos los días, más allá de lo que le sirve a la gerencia?
- 2. ¿Quiénes son los usuarios con más influencia informal dentro del equipo comercial, y están involucrados en el proyecto?
- 3. ¿El liderazgo cambió su propio comportamiento, o sigue pidiendo reportes armados a mano por fuera del CRM?
- 4. ¿Los datos son confiables desde el primer día, o el equipo tiene que "perdonar" duplicados y campos vacíos?
Cómo lo encaramos en un proyecto real
Cuando Zarasa entra a un proyecto — ya sea una implementación nueva o el rescate de una que quedó con baja adopción — la primera conversación no es sobre funcionalidades. Suele ser sobre qué le resuelve el sistema a la persona que va a cargar datos todos los días, quiénes son los usuarios con más influencia dentro del equipo comercial, y qué tan dispuesto está el liderazgo a cambiar su propia forma de pedir información. Esas respuestas definen la configuración mucho más que cualquier lista de objetos y campos.
Si tenés Salesforce hace tiempo y sentís que el equipo lo usa "porque hay que hacerlo" y no porque les sirve, esa brecha casi siempre se puede diagnosticar y corregir sin rehacer el proyecto entero.
¿Tu equipo usa Salesforce por obligación y no por convicción?
Diagnosticamos dónde está la brecha de adopción en tu implementación y te decimos exactamente cómo corregirla, sin compromiso.
Hablemos de tu casoPreguntas frecuentes
¿La baja adopción de Salesforce se arregla con más capacitación?
Casi nunca. Según el propio material de Trailhead, los usuarios adoptan una herramienta cuando la perciben fácil de usar y sienten que les resuelve algo que les importa. Si falta alguna de las dos condiciones, la adopción no sucede sin importar cuánta capacitación se dé. El problema suele ser de diseño del sistema y de gestión del cambio, no de formación.
¿Hay que rehacer la implementación para mejorar la adopción?
En general no. La brecha entre un equipo que usa Salesforce por obligación y uno que lo usa porque le sirve casi siempre se puede diagnosticar y corregir sobre la implementación existente, ajustando diseño, procesos y calidad de datos sin rehacer el proyecto entero.
¿Quiénes deberían ser los "champions" o usuarios avanzados?
No necesariamente los que más venden, sino los vendedores con más ascendencia informal sobre el resto del equipo. Involucrarlos antes del lanzamiento general — que prueben el sistema, den feedback real y encuentren un caso de uso donde Salesforce les ahorre tiempo — hace que el resto copie el comportamiento sin necesidad de discursos.
¿Qué rol juega la calidad de los datos en la adopción?
Un rol central. Contactos duplicados, campos vacíos y oportunidades desactualizadas le enseñan al usuario que cargar información no importa. Datos malos generan desconfianza, la desconfianza genera menos carga de información y eso empeora los datos. Romper ese círculo requiere un esfuerzo visible de limpieza y gobernanza de datos al inicio del proyecto.