En este artículo
Una auditoría de Salesforce tiene sentido cuando aparecen problemas recurrentes y no existe una causa única y evidente. Si los informes no generan confianza, el equipo trabaja fuera del CRM, pequeños cambios provocan efectos inesperados o distintas áreas señalan problemas diferentes, conviene diagnosticar antes de decidir qué modificar.
No todo problema necesita una auditoría. Una incidencia concreta con una causa conocida puede resolverse directamente. La auditoría empieza a tener valor cuando el síntoma se repite, afecta al trabajo real y no está claro si el origen está en el proceso, la configuración, los datos, las integraciones o la forma de utilizar Salesforce.
¿Qué señales deberían preocuparte?
La señal más clara no es que exista un error. Es que empiezan a aparecer varias fricciones relacionadas y cada equipo las explica de una forma distinta.
Dirección puede decir que no confía en el forecast. Ventas puede responder que Salesforce no refleja cómo trabaja. IT puede señalar excepciones y automatizaciones difíciles de tocar. Y el responsable del CRM puede tener una lista creciente de peticiones sin saber cuáles resolverán realmente el problema.
Hay algunas situaciones especialmente útiles para detectar que merece la pena mirar el conjunto:
Los informes importantes necesitan una comprobación manual antes de utilizarlos.
El equipo mantiene Excel paralelos para completar procesos que deberían ocurrir en Salesforce.
Cambios aparentemente pequeños requieren cada vez más análisis o generan efectos inesperados.
Distintos equipos utilizan Salesforce de maneras diferentes para hacer el mismo trabajo.
Los usuarios repiten las mismas quejas después de haber aplicado correcciones puntuales.
Hay procesos que han cambiado en el negocio, pero Salesforce sigue representando la versión anterior.
Se acumulan incidencias, peticiones y mejoras sin un criterio claro para priorizarlas.
Una señal aislada no demuestra que necesites una auditoría. Varias señales persistentes sí indican que conviene dejar de tratar cada problema por separado.
Arreglamos cosas en Salesforce, pero no tenemos claro si estamos resolviendo las causas o solo apagando fuegos.
Ese es precisamente el punto en el que el diagnóstico empieza a ser más valioso que otro cambio aislado.
¿Cuándo deja de ser un problema puntual?
Una incidencia puntual tiene normalmente un alcance limitado y una causa identificable. Un problema estructural reaparece, afecta a más de un proceso o necesita trabajo manual para compensarlo.
| Síntoma | Problema puntual | Señal de fondo |
|---|---|---|
| Informe incorrecto | Error localizado | Se revisa manualmente cada mes |
| Queja de usuario | Duda concreta | Varios perfiles crean el mismo atajo |
| Cambio complejo | Dependencia conocida | Cada cambio genera sorpresas |
| Excel paralelo | Análisis temporal | Forma parte del proceso habitual |
| Datos distintos | Incidencia identificada | Nadie sabe qué sistema creer |
La frecuencia importa, pero también el impacto.
Un pequeño problema que obliga a cinco personas a reconciliar datos todas las semanas puede ser más relevante que una incidencia técnica llamativa que ocurre una vez al año.
También importa la dependencia. Si para corregir un campo tienes que revisar automatizaciones, informes, permisos y procesos relacionados, el problema ya no está solo en ese campo. Salesforce ha acumulado relaciones que conviene entender antes de seguir modificando.
¿Por qué el mismo síntoma puede tener varias causas?
El error más común es saltar directamente desde el síntoma a la solución.
«Los comerciales no actualizan las oportunidades» se convierte en «necesitan formación».
«El forecast no es fiable» se convierte en «necesitamos otro dashboard».
«La integración falla» se convierte en «hay que rehacerla».
Pero un mismo síntoma puede tener orígenes completamente distintos.
Un forecast poco fiable puede aparecer porque las fases del pipeline ya no representan la venta real. También porque los comerciales no tienen ningún motivo operativo para mantener las oportunidades actualizadas. O porque determinados datos llegan tarde desde otro sistema.
En los tres casos el síntoma es el mismo: dirección no confía en el forecast.
La intervención no debería ser la misma.
Lo mismo ocurre con la baja adopción. Un usuario puede dejar Salesforce porque no sabe utilizar una función, porque el proceso configurado le obliga a dar demasiados pasos o porque su manager sigue dirigiendo el pipeline desde Excel.
Más formación solo resuelve el primero.
Esta es la razón principal para auditar antes de actuar cuando hay varias hipótesis posibles: evitar invertir en una solución correcta para el problema equivocado.
¿Cómo saber si necesitas una auditoría?
Puedes tomar la decisión con una secuencia bastante sencilla.
- 01
¿El problema es concreto y conocéis su causa? Si la respuesta es sí, probablemente podéis corregirlo sin una auditoría general.
- 02
¿El problema reaparece después de corregirlo? Si vuelve con otra forma o en otro equipo, conviene ampliar el diagnóstico.
- 03
¿Hay varias explicaciones posibles? Si Ventas, IT y dirección atribuyen el problema a causas distintas, no empieces eligiendo una de ellas.
- 04
¿Sabéis cómo debería funcionar Salesforce después del cambio? Si el estado futuro está claro, probablemente estás ante un proyecto de evolución.
- 05
¿No está claro qué conservar, qué cambiar o qué priorizar? Ese es el escenario más claro para una auditoría.
La diferencia entre auditoría y evolución es importante.
Una auditoría responde principalmente a: ¿qué está pasando y qué deberíamos priorizar?
La evolución responde a: ¿qué vamos a cambiar para mejorar Salesforce?
Puedes necesitar las dos, pero el orden importa. Si todavía no sabes dónde está el problema, empezar a evolucionar significa convertir hipótesis en backlog.
Y un backlog basado en hipótesis suele crecer mucho más rápido de lo que se resuelve.
¿Qué deberías revisar antes de cambiar nada?
No necesitas realizar una auditoría técnica por tu cuenta antes de pedir ayuda. Sí conviene llegar con ejemplos concretos del trabajo que hoy genera dudas.
Empieza por observar dónde se rompe la confianza o aparece trabajo paralelo.
¿Qué informe importante revisáis manualmente antes de una reunión?
¿Qué parte del proceso sigue ocurriendo en Excel, correo u otra herramienta?
¿Qué cambio reciente resultó mucho más difícil de lo esperado?
¿Qué queja de usuarios aparece de forma recurrente?
¿Qué dato genera discusión porque dos sistemas muestran respuestas diferentes?
¿Qué proceso real ha cambiado sin que Salesforce haya cambiado con él?
¿Qué petición lleva meses en el backlog porque nadie tiene claro cómo abordarla?
Estas preguntas producen algo más útil que una lista genérica de funcionalidades que «no van bien».
Producen situaciones observables.
Por ejemplo, «tenemos problemas de datos» dice poco.
«Dirección prepara el forecast exportando las oportunidades y corrigiendo fechas de cierre en Excel antes del comité» permite empezar a investigar un proceso concreto.
«Salesforce está poco adoptado» también dice poco.
«El equipo actualiza las oportunidades el viernes porque el lunes hay reunión comercial» describe un comportamiento que puede analizarse.
El objetivo inicial no es diagnosticar tú mismo la causa. Es distinguir hechos de opiniones para no empezar el proyecto desde una conclusión prematura.
¿Qué debería aclarar una auditoría?
Una auditoría útil debería reducir incertidumbre.
Al terminar, la empresa debería entender mejor qué problemas tienen impacto real, qué causas son prioritarias y qué tipo de intervención tiene sentido después.
No todo lo detectado tiene que convertirse en proyecto.
Parte del valor del diagnóstico consiste precisamente en separar:
lo urgente de lo que puede esperar;
una incidencia de un problema recurrente;
un problema de configuración de un problema de proceso;
una necesidad de formación de un problema de adopción;
una mejora concreta de una evolución más amplia;
una fricción local de un problema que afecta a varias áreas.
El resultado que importa no es tener una lista más larga de cosas por hacer.
Es poder tomar decisiones con más criterio.
Si al terminar el diagnóstico descubres que Salesforce refleja bien el proceso pero los usuarios no saben realizar determinadas tareas, probablemente el siguiente paso estará cerca de la formación.
Si el equipo sabe utilizarlo pero sigue trabajando fuera porque el proceso configurado no encaja, el problema se acerca más a adopción y evolución.
Si distintas partes del sistema generan problemas relacionados y no hay una causa evidente, habrá que priorizar el trabajo antes de tocar piezas.
Y si Salesforce necesita cambiar porque el negocio ha cambiado, el diagnóstico debería permitir pasar a una evolución con un alcance mucho más claro.
Una auditoría de Salesforce no debería empezar por la pregunta «¿qué podemos mejorar?». Debería empezar por una anterior:
¿Qué está impidiendo hoy que Salesforce funcione como necesita el negocio?
Cuando esa respuesta todavía no está clara, seguir acumulando cambios puede aumentar el ruido.
Primero entiende el problema.
Después decides qué merece la pena cambiar.
Albert Pallejà · CEO de Kaizen
Partner de Salesforce desde 2011 y más de 300 proyectos entregados, con experiencia concentrada en manufacturing, hospitality y servicios profesionales. Escribe sobre lo que se ve en las instalaciones reales, no sobre el roadmap de producto.