Cómo recuperar una implementación fallida de Salesforce

Invertiste en Salesforce esperando más orden, visibilidad y control. Sin embargo, pasan los meses y el equipo continúa trabajando en planillas, los reportes no coinciden con la realidad y cada modificación parece crear un problema nuevo. La conclusión empieza a repetirse: "Salesforce no nos funcionó".

Esa frase describe el resultado, pero no explica la causa.

El problema puede estar en el alcance contratado, en procesos que nunca se definieron, en una configuración difícil de mantener, en integraciones inestables, en datos poco confiables o en una experiencia que obliga a trabajar fuera del sistema. Por eso, una recuperación no comienza agregando campos, construyendo otro dashboard o impartiendo una nueva capacitación. Comienza respondiendo tres preguntas:

1. ¿Qué impide que Salesforce genere valor?
2. ¿Qué parte de la implementación todavía sirve?
3. ¿Conviene corregir, reconstruir por etapas o empezar de nuevo?

"SALESFORCE NO FUNCIONA" ES UN SÍNTOMA, NO UN DIAGNÓSTICO

Los síntomas suelen ser fáciles de reconocer:

• El equipo mantiene planillas paralelas.
• Los reportes no reflejan la operación.
• Existen registros incompletos o duplicados.
• Algunas automatizaciones fallan o nadie sabe por qué existen.
• Los usuarios ingresan solo cuando se les exige.
• Una modificación pequeña afecta otras partes del sistema.
• Las integraciones requieren correcciones manuales frecuentes.

Antes de cambiar la plataforma, hay que encontrar la causa.

LAS SEIS DIMENSIONES DEL DIAGNÓSTICO

No todas las implementaciones fallan de la misma manera ni deben revisarse siguiendo una secuencia rígida. Una evaluación seria debe cubrir seis dimensiones y estudiar cómo se afectan entre sí.

1. Ajuste entre Salesforce y el negocio

La primera pregunta no es técnica: ¿Salesforce fue contratado para resolver el problema correcto?

Puede existir una diferencia entre lo que el negocio esperaba y lo que realmente se compró. También puede haberse elegido una nube, edición o conjunto de licencias que no cubre las capacidades asumidas por los usuarios.

Conviene identificar las funciones indispensables y verificar si están incluidas, habilitadas y correctamente asignadas. Si existe una brecha de alcance o licenciamiento, ninguna configuración podrá compensarla por completo.

1. Procesos y responsabilidades

Salesforce puede estar correctamente configurado y producir malos resultados si intenta automatizar un proceso que cada área ejecuta de forma diferente.

Pide a dos personas del mismo equipo que expliquen cómo gestionan un caso real. Si las respuestas difieren, primero hay que acordar el proceso, sus responsables y sus excepciones: quién actualiza una oportunidad, cuándo avanza un lead, qué datos son obligatorios y cuál sistema es la fuente oficial de cada información.

Configurar antes de resolver estas decisiones traslada la ambigüedad del negocio a la plataforma.

1. Arquitectura, configuración e integraciones

Aquí se revisa si la solución representa la operación sin introducir complejidad innecesaria: modelo de datos, componentes estándar y personalizados, automatizaciones, permisos, dependencias, documentación e integraciones.

Una señal práctica aparece al observar a un usuario mientras completa una tarea habitual. Si necesita demasiados pasos, encuentra campos que no entiende o debe salir de Salesforce para terminar, el problema no puede atribuirse solo a falta de capacitación.

También hay que revisar los sistemas conectados. Un CRM puede parecer inconsistente cuando el error real está en la sincronización con el ERP, facturación, marketing u otra plataforma crítica.

1. Calidad y gobierno de los datos

Un reporte solo puede ser tan confiable como los datos que lo alimentan. La revisión debe considerar exactitud, completitud, duplicación, antigüedad y responsables.

Una muestra de registros recientes puede revelar campos críticos vacíos, etapas desactualizadas o valores que los usuarios interpretan de manera diferente. Después hay que seguir el dato hasta su origen: carga manual, migración, formulario, integración o automatización.

Limpiar registros sin corregir la causa solo aplaza el problema.

1. Experiencia de usuario y adopción

Los inicios de sesión son una señal temprana, pero no prueban que Salesforce esté incorporado al trabajo diario. Un usuario puede ingresar con frecuencia y continuar gestionando lo importante en una planilla.

La adopción debe observarse en comportamientos concretos: oportunidades actualizadas, actividades registradas, tareas críticas completadas dentro del sistema, menor cantidad de datos incompletos y retiro efectivo de planillas paralelas.

Cuando la adopción es baja, hay que investigar la causa antes de prescribir capacitación. Puede faltar acompañamiento, pero también puede existir una solución lenta, confusa o desconectada de la operación.

1. Gobierno y evolución

Una implementación puede salir correctamente a producción y deteriorarse después si nadie queda a cargo de administrarla.

El diagnóstico debe aclarar quién prioriza solicitudes, quién puede cambiar la configuración, cómo se prueban y despliegan los cambios, dónde se documentan las decisiones, quién responde por la calidad de los datos y cómo se monitorean las integraciones.

Sin gobierno, las soluciones puntuales se acumulan como deuda técnica. Cada mejora cuesta más y aumenta el riesgo operativo.

EVALUACIÓN INICIAL Y AUDITORÍA COMPLETA

Una evaluación inicial confirma el problema y localiza las áreas de mayor riesgo. Puede incluir entrevistas breves, observación de tareas, revisión de una muestra de datos y un inventario general de automatizaciones e integraciones.

Una auditoría completa profundiza en procesos, arquitectura, seguridad, licencias, datos, adopción e integraciones. Su duración depende del número de usuarios, productos, países, personalizaciones y sistemas conectados.

El resultado debería incluir:

• Causas y dependencias.
• Riesgos que requieren atención inmediata.
• Aquello que conviene conservar.
• Una recomendación de recuperación.
• Prioridades, responsables y criterios de salida.
• Una línea base para medir avances.

Una reunión comercial puede orientar el siguiente paso, pero no reemplaza este trabajo.

¿CORREGIR, RECONSTRUIR O REIMPLEMENTAR?

La decisión debe considerar el valor de lo existente y el costo futuro de mantenerlo.

Corregir puede convenir cuando el modelo principal sigue siendo válido, las dependencias se entienden y los problemas pueden aislarse.

Reconstruir por etapas puede convenir cuando algunos módulos funcionan pero otros concentran el riesgo, la operación no puede detenerse y conviene migrar gradualmente.

Reimplementar puede convenir cuando la solución ya no representa al negocio, tiene dependencias impredecibles, personalización difícil de mantener o documentación insuficiente.

Reimplementar no obliga a perder todo el historial. La información útil puede conservarse mediante una estrategia de migración y archivo, sin trasladar automáticamente aquello que generó el problema.

La inversión pasada tampoco debería decidir el futuro por sí sola. "Ya gastamos demasiado para cambiar" y "es mejor empezar de cero" son reacciones comprensibles, pero ninguna sustituye un diagnóstico.

UN PLAN GUIADO POR CRITERIOS, NO SOLO POR FECHAS

Los planes ayudan a comunicar una recuperación, pero cada fase necesita condiciones claras para poder cerrarse.

Se protegen las tareas diarias y se priorizan bloqueos críticos, riesgos de seguridad, datos esenciales y fallas de integración. Se evita agregar funcionalidades mientras la base sea inestable.

Se definen procesos y responsables, se corrigen las causas de la mala calidad de datos y se ajusta la solución al trabajo real. La fase termina cuando las tareas críticas pueden completarse dentro del sistema con información confiable.

Con una base estable, se retoman automatizaciones, integraciones y mejoras. Cada cambio debe vincularse con un resultado, contar con pruebas y tener un responsable posterior al despliegue.

La gestión del cambio atraviesa las tres fases. Las personas necesitan entender qué cambia, por qué y dónde obtener ayuda.

CÓMO MEDIR LA RECUPERACIÓN

La medición debe comenzar antes de realizar cambios. Sin una línea base, cualquier mejora termina discutiéndose mediante percepciones.

Adopción: usuarios que completan las tareas esperadas dentro de Salesforce.

Actualización: oportunidades o casos sin actividad durante el plazo definido.

Calidad: registros con campos críticos completos y tasa de duplicados.

Operación: procesos terminados sin planillas ni correcciones manuales.

Integraciones: errores, reintentos y registros pendientes de sincronización.

Decisión: diferencia entre los reportes y la realidad validada por el negocio.

Los logins, la creación de registros y las actualizaciones son señales útiles, pero deben relacionarse con el comportamiento que la organización busca cambiar. Medir actividad sin contexto puede crear una sensación falsa de avance.

CUÁNDO CONVIENE BUSCAR AYUDA EXTERNA

Un equipo interno puede resolver problemas acotados si conoce la plataforma y dispone de tiempo para investigar. La ayuda externa cobra valor cuando existen múltiples integraciones, varios países o unidades de negocio, grandes volúmenes de datos, dependencias poco documentadas o intentos anteriores de recuperación que no perduraron.

Antes de contratar, pide claridad sobre el alcance, los participantes, los entregables, los criterios de priorización y la forma de medir resultados. Una auditoría útil debe ayudarte a decidir, no limitarse a enumerar fallas técnicas.

RECUPERAR SALESFORCE EMPIEZA POR ENTENDER QUÉ FALLÓ

Una implementación con problemas no se recupera acumulando parches. Se recupera identificando la causa, conservando lo que aporta valor y ordenando el resto según su impacto en la operación.

El primer paso no es cambiar Salesforce. Es entenderlo.