Los errores más comunes al implementar Sales Cloud por primera vez

De qué se trata realmente el problema

Después de acompañar varios proyectos de Sales Cloud desde cero, los errores que se repiten tienen un patrón bastante definido: son de planificación, de datos y de gente, no de configuración técnica. Un campo mal configurado se corrige en diez minutos. Un org construido sin objetivos claros, con datos sucios y un equipo que no adoptó el sistema se corrige rehaciendo el trabajo.

Esta guía está basada en la documentación oficial de Salesforce —Trailhead, Implementation Guide— y cubre los cinco errores que con más frecuencia complican proyectos que técnicamente podrían haber salido bien.

1. Arrancar a configurar sin objetivos definidos

Es tentador entrar directo al org y empezar a crear campos, layouts y procesos. Pero Salesforce mismo estructura su guía de implementación de Sales Cloud pidiendo lo contrario: primero definir los objetivos de negocio y cómo se van a medir, y recién después traducirlos en configuración.

La guía de Trailhead para el rollout de Sales Cloud lo plantea con un ejemplo simple: una empresa que quiere mejorar el seguimiento de ingresos define primero qué procesos son críticos, involucra a su equipo de ventas para entender los resultados esperados, y documenta el proceso actual antes de tocar nada.

Lo que pasa cuando te saltás este paso: terminás con un org técnicamente funcional pero que no refleja cómo trabaja realmente el equipo de ventas. Y ese desajuste no se corrige con más configuración, se corrige rehaciendo el trabajo.

Antes de crear el primer campo personalizado, conviene tener una respuesta clara a tres preguntas: ¿qué problema de negocio estás resolviendo?, ¿cómo vas a saber si lo resolviste?, y ¿quién en el negocio —no en IT— es el dueño de esa definición de éxito?

2. Migrar datos sin pensar en duplicados

Este es el error que más dolores de cabeza genera después del go-live, y casi nunca se toma en serio a tiempo. La migración de datos suele tratarse como un paso técnico de "subir el CSV", cuando en realidad es donde se decide si el CRM va a ser confiable o no.

Salesforce tiene herramientas nativas específicamente para esto: reglas de coincidencia (matching rules) y reglas de duplicados (duplicate rules). Las reglas de coincidencia definen qué criterios usa Salesforce para detectar que dos registros podrían ser el mismo —por ejemplo, contactos con nombres similares detectados por coincidencia difusa—, y las reglas de duplicados definen qué hacer cuando se detecta uno: bloquear la creación, dejarla pasar con una alerta, o agregar el posible duplicado a un reporte para que un gerente lo revise.

El problema real no es que Salesforce no tenga estas herramientas, es que casi nadie las configura antes de migrar los datos existentes. Se importa todo tal cual viene del sistema anterior, y las reglas de duplicados se activan recién cuando alguien nota que hay tres registros distintos para el mismo cliente. En ese punto ya no es un ajuste de configuración: es un proyecto de limpieza de datos completo, con reps que ya perdieron confianza en que lo que ven en el sistema es correcto.

3. Entrenar a todos igual

Otro patrón que se repite: se agenda una sesión de "capacitación en Salesforce" de dos horas para todo el equipo comercial, sin distinguir entre lo que necesita saber un ejecutivo de cuentas, un gerente de ventas y un representante que recién arranca.

El enfoque que documenta Trailhead para el desarrollo de un plan de capacitación es más simple de lo que parece pero rara vez se aplica: primero identificar la audiencia (quién necesita ser entrenado), después definir escenarios relevantes para cada rol (qué hace esa persona día a día en Salesforce), y recién ahí armar el plan. No es lo mismo entrenar a un rep en cómo revisar el historial de actividad de una cuenta antes de una reunión y cómo actualizar una oportunidad después, que entrenar a un gerente en cómo leer un dashboard de pipeline.

Y hay un punto que se suele ignorar por completo: la capacitación no es un evento único antes del go-live. Es algo que hay que sostener después, cuando aparecen dudas reales de uso diario, no las que se anticiparon en la sesión de onboarding, sino las que surgen cuando el usuario ya está usando el sistema para su trabajo real.

4. No planificar hitos realistas

"¿Cuánto tarda esto?" es la pregunta que más rápido genera fricción cuando no se responde con un plan concreto. La guía de implementación de Salesforce recomienda trabajar hacia atrás desde una fecha de go-live definida, y contemplar hitos básicos en este orden:

• Agregar usuarios
• Configurar el sistema según el negocio
• Importar datos
• Habilitar funcionalidades que aumenten la productividad
• Entrenar usuarios

No como pasos paralelos improvisados. El error típico es fijar una fecha de lanzamiento antes de tener claro cuánto tiempo real requiere cada uno de estos pasos, especialmente la limpieza y migración de datos, que casi siempre se subestima.

5. Tratar el go-live como la línea de meta

Para nosotors, el error más caro de todos porque es el más silencioso. El proyecto se planifica, se ejecuta, se lanza y ahí termina la atención. Pero Salesforce estructura la adopción de usuarios como un proceso continuo con fases que se repiten en el tiempo: onboarding, descubrimiento de funcionalidades, ayuda y resolución de problemas, y aprendizaje más profundo. No es una línea que termina en el lanzamiento, es un ciclo que se repite cada vez que algo cambia en el org.

En la práctica, esto significa monitorear indicadores simples después del go-live: tasas de login, registros creados, usuarios activos, y cruzarlos con lo que se esperaba ver. Si los logins o las actualizaciones de registros están por debajo de lo anticipado, generalmente no es un problema técnico: es una señal de que hace falta más soporte o capacitación en ese momento específico, no en el que se planificó originalmente.

Lo que realmente cambia el resultado

Ninguno de estos errores requiere una solución técnica compleja. Requieren disciplina en la secuencia: definir objetivos antes de configurar, resolver la calidad de datos antes de migrar, entrenar por rol en vez de en bloque, planificar hitos realistas, y sostener la adopción después del lanzamiento en vez de darla por hecha.

Salesforce documenta cada uno de estos pasos de forma bastante clara en sus propios recursos. El problema casi nunca es que la información no exista, sino que se salta bajo presión de tiempo.

Fuentes oficiales de Salesforce

• Trailhead — Sales Cloud Implementation Guide / Chart Your Course
• Trailhead — Create an Effective Business Strategy with Sales Cloud
• Trailhead — Improve Data Quality in Salesforce
• Trailhead — Training Plan Development Steps
• Trailhead — Get Started with User Engagement / Design a User Engagement Journey