Cambiar de partner de Salesforce: qué revisar antes de tomar la decisión

Cambiar de partner de Salesforce puede ser la decisión correcta cuando la relación actual está impidiendo resolver problemas o evolucionar la plataforma. Pero un nuevo proveedor no arregla por sí solo una org mal diseñada, datos poco fiables o un proceso que la propia empresa no tiene claro.

Antes de cambiar, conviene separar qué está fallando en Salesforce, qué depende del partner y qué depende de la propia organización.

¿Cómo saber si el problema es realmente el partner?

No basta con que una mejora haya tardado, ni con que haya habido una incidencia mal resuelta. Una relación con un partner debería valorarse mirando un patrón. Por ejemplo:

• Salesforce lleva tiempo sin evolucionar aunque el negocio haya cambiado.

• Los mismos problemas reaparecen.

• El equipo plantea necesidades de negocio y la conversación acaba reducida a campos, objetos o tickets.

• Hay un backlog largo, pero poca claridad sobre qué debería hacerse primero.

• Cada cambio se ejecuta de forma aislada y luego aparecen efectos en otras partes de Salesforce.

• La organización depende demasiado del partner para entender qué tiene montado.

O simplemente tienes la sensación de que estás pagando por mantener Salesforce vivo, pero no por hacerlo más útil.

Una de estas situaciones aislada no demuestra que necesites cambiar de partner. Varias mantenidas en el tiempo sí justifican revisar qué está ocurriendo.

Señales de que la relación con tu partner necesita una revisión

1. Salesforce ha dejado de seguir al negocio

El proceso comercial ha cambiado. Hay nuevos canales, ha cambiado la forma de gestionar distribuidores, Marketing trabaja de otra manera y Customer Service necesita información nueva. Pero Salesforce continúa prácticamente igual que hace años.

Una plataforma como Salesforce necesita evolucionar porque el negocio también lo hace. Si cada cambio resulta demasiado difícil, caro o lento de plantear, conviene entender por qué: puede ser un problema de prioridades internas, puede ser deuda acumulada en la configuración, o puede ser que la relación con el partner se haya vuelto demasiado reactiva.

2. Todo se ha convertido en tickets

• «Necesitamos añadir este campo.»

• «Este informe no cuadra.»

• «Hay que cambiar esta automatización.»

• «Queremos una nueva vista.»

Cada petición puede resolverse correctamente y aun así existir un problema, porque alguien tiene que hacerse otra pregunta: ¿por qué estamos pidiendo todos estos cambios?

Quizá el informe no cuadra porque los datos no se mantienen. Quizá el nuevo campo intenta compensar un proceso mal definido. Quizá hay cinco automatizaciones porque nunca se revisó el flujo completo.

Si la relación consiste únicamente en pedir y ejecutar cambios, Salesforce puede acumular soluciones locales sin resolver problemas de fondo.

3. El backlog crece, pero nadie sabe qué es realmente prioritario

Hay cuarenta peticiones pendientes. Ventas necesita unas, Marketing otras, Customer Service tiene su propia lista e IT quiere resolver problemas técnicos. Todas parecen importantes, y cada reunión termina moviendo las prioridades.

Un backlog no es una estrategia de evolución. El partner debería poder participar en una conversación donde la pregunta no sea solo qué hacemos primero, sino esta otra:

¿Qué problema de negocio merece realmente que cambiemos Salesforce?

Si esa conversación ha desaparecido, merece la pena revisar la relación.

4. El partner entiende Salesforce, pero no termina de entender cómo trabaja la empresa

Una solución puede ser técnicamente correcta y operativamente inútil. El pipeline funciona, los campos están creados y las automatizaciones se ejecutan. Pero los comerciales siguen usando Excel porque las oportunidades no representan cómo venden.

O Customer Service tiene Salesforce abierto mientras consulta otro sistema para saber qué le ha pasado realmente al cliente. O Marketing trabaja con segmentos que no coinciden con los que utiliza Ventas.

El conocimiento técnico es necesario, pero no basta: Salesforce tiene que reflejar una forma concreta de trabajar.

5. Dependéis del partner para entender vuestra propia org

Preguntas algo relativamente sencillo: «¿por qué funciona así este proceso?». Y nadie dentro de la organización lo sabe. «Eso lo hizo el partner.»

• Automatizaciones cuyo origen no está claro.

• Decisiones antiguas que nadie recuerda.

• Dependencias que solo conoce una persona externa.

• Documentación incompleta o difícil de localizar.

Eso no significa necesariamente que el partner haya trabajado mal: muchas implementaciones acumulan años de decisiones, equipos y cambios. Pero sí genera un riesgo importante si estás pensando en un relevo.

6. Los problemas se corrigen, pero vuelven

Se arregla el informe y tres meses después vuelve a fallar. Se modifica un proceso y aparece otro Excel paralelo. Se simplifica una pantalla y los usuarios siguen sin actualizar la información.

Cuando los síntomas vuelven, merece la pena preguntarse si estamos resolviendo causas o simplemente incidencias. Un cambio de partner puede ser útil, pero solo si el siguiente empieza por entender por qué ocurre el problema.

No todo problema con Salesforce es un problema de partner

Esta parte es importante. Cambiar de partner es una decisión relativamente visible; cambiar algunas dinámicas internas puede ser más incómodo.

Imagina que Dirección no confía en el forecast y las oportunidades no se actualizan. Es fácil concluir que Salesforce no funciona bien y, después, que el partner no lo ha hecho bien.

Puede ser. Pero también puede ocurrir que las fases comerciales nunca se hayan definido con suficiente claridad. O que cada manager las interprete de una forma. O que actualizar Salesforce no tenga ninguna utilidad para el comercial y solo sirva para preparar informes. O que Dirección continúe pidiendo el forecast en Excel aunque Salesforce esté configurado correctamente.

Un nuevo partner puede ayudarte a cambiar esas cosas. Pero no puede sustituir decisiones que corresponden a la propia organización.

¿Qué situaciones pueden confundirse con un problema de partner?

Esta distinción importa porque cambiar de partner sin entender la causa puede cambiar el proveedor y conservar exactamente el mismo problema.

¿Qué deberías tener claro antes de cambiar?

No necesitas conocer hasta el último detalle técnico de Salesforce, pero tampoco conviene empezar el relevo con una caja negra. Antes de cambiar, intenta responder al menos estas preguntas.

¿Qué problemas quieres resolver?

No empieces por la lista de tickets, empieza por el negocio. «Necesitamos diecisiete cambios» dice poco. «Dirección no confía en el forecast porque las oportunidades no reflejan la situación real» permite empezar una conversación útil. «Customer Service consulta tres sistemas para responder una incidencia» también. «Cada distribuidor se gestiona de una forma y no tenemos un pipeline consolidado» también.

El nuevo partner necesita entender primero esto.

¿Qué funciona bien y no quieres perder?

Cambiar de partner no significa empezar Salesforce de cero. Probablemente hay procesos que funcionan, automatizaciones útiles, informes que el equipo utiliza, integraciones necesarias y formas de trabajar que ya están adoptadas. Un relevo bien planteado también debe identificar qué hay que conservar.

¿Qué lleva meses esperando?

Revisa el backlog, pero no para entregárselo sin más al nuevo partner. Clasifícalo: ¿qué es una incidencia? ¿Qué es una mejora? ¿Qué petición ya no tiene sentido? ¿Qué está bloqueando realmente al negocio? ¿Qué existe simplemente porque alguien lo pidió hace un año?

Cambiar de partner es una buena oportunidad para dejar de tratar el backlog como una lista cronológica.

¿Dónde siguen apareciendo Excels y procesos paralelos?

Los sistemas paralelos cuentan una historia. Puede que exista un Excel porque Salesforce no cubre una necesidad, porque la cubre mal, porque los usuarios no saben usarla, porque el proceso configurado no corresponde al real o simplemente porque nadie ha cuestionado ese Excel en cinco años.

No des por hecho que todo debe migrarse a Salesforce. Pero entiende por qué existe.

¿Qué sabemos de la org que tenemos?

No necesitas convertir esta revisión en un proyecto de arqueología. Sí necesitas evitar que toda la explicación del sistema sea «pregúntale al partner anterior». Estas son las ocho cosas que conviene poder situar antes de un relevo:

• Prioridades pendientes: qué está esperando y qué bloquea al negocio.

• Procesos que no funcionan: dónde el proceso configurado no es el real.

• Configuración y automatizaciones relevantes: lo que nadie quiere tocar y por qué.

• Integraciones: con qué sistemas habla Salesforce y cuáles son críticos.

• Datos: en qué información se confía y en qué no.

• Adopción: quién usa Salesforce de verdad y para qué.

• Documentación disponible: qué está escrito y qué vive en la cabeza de alguien.

• Decisiones pendientes: lo que la organización todavía no ha decidido.

¿Qué deberías preguntar a un posible nuevo partner?

Una primera reunión no debería consistir únicamente en enseñarle el backlog. Hay preguntas que permiten saber bastante más.

«¿Qué necesitaríais revisar antes de proponernos cambios?»

Una respuesta útil debería empezar por entender la situación, no por vender inmediatamente una solución.

«¿Cómo distinguiríais qué debemos mantener y qué debemos cambiar?»

Un Salesforce con años de uso contiene decisiones buenas y malas. Cambiar de partner no debería significar cuestionarlo todo.

«¿Cómo vais a entender nuestro proceso real?»

Esto es especialmente importante cuando el problema no es puramente técnico. Si el pipeline, el canal, el servicio técnico o la relación entre Marketing y Ventas son importantes, el nuevo partner necesita entenderlos.

«¿Cómo priorizaríais nuestro backlog?»

La respuesta no debería ser simplemente por orden de llegada. Conviene saber cómo conecta las peticiones con problemas y prioridades de negocio.

«¿Qué necesitáis del partner anterior?»

La transición puede requerir información, documentación y contexto. Es mejor saberlo antes que descubrir dependencias cuando el relevo ya está en marcha.

«¿Qué problemas veis que quizá no se solucionen cambiando de partner?»

Esta pregunta es especialmente útil. Un nuevo proveedor tiene incentivos evidentes para decir que puede mejorar la situación; también debería ser capaz de señalar qué decisiones dependen de tu propia organización.

¿Hay que tenerlo todo documentado antes de hacer el cambio?

No. Si precisamente uno de los problemas es la dependencia del partner actual, es posible que no dispongas de toda la documentación que te gustaría. Eso no debería bloquear la decisión.

Sí conviene saber qué tienes y qué no tienes: qué procesos están claros, qué integraciones son críticas, qué personas internas conocen mejor Salesforce, qué problemas están abiertos y qué información depende hoy de terceros.

El objetivo no es llegar al nuevo partner con una org perfectamente documentada. Es evitar llegar sin saber siquiera dónde están las incógnitas.

¿Y si no sé si necesito cambiar de partner o arreglar Salesforce?

Es una situación bastante habitual. Ves los síntomas, pero no está clara la causa. El forecast no es fiable, los usuarios trabajan fuera, hay automatizaciones que nadie quiere tocar, los informes generan discusiones, el backlog crece y la relación con el partner actual tampoco convence. Pero es difícil saber qué parte explica qué.

Ahí tiene sentido separar el diagnóstico de la decisión de cambio. Una auditoría de Salesforce puede ayudarte a entender primero cuál es el punto de partida.

Porque quizá necesites otro partner. Quizá necesites evolucionar un Salesforce que ya está en producción. Quizá el problema principal sea de adopción o de gobierno interno. O una combinación de varias cosas.

La decisión mejora mucho cuando sabes qué estás intentando resolver.

Cambiar de partner no debería empezar por buscar otro partner

Debería empezar por entender por qué estás pensando en cambiar.

• ¿Qué está fallando?

• ¿Qué debería estar ocurriendo y no ocurre?

• ¿Qué parte de Salesforce ya no encaja?

• ¿Qué funciona y quieres conservar?

• ¿Dónde depende demasiado la empresa de terceros?

• ¿Qué tendría que ser distinto dentro de un año para considerar que el cambio ha valido la pena?

Con esas respuestas puedes evaluar mucho mejor qué debería aportar un partner Salesforce. Y también puedes llegar a una conclusión perfectamente válida: que todavía no necesitas cambiar.

Puede que necesites poner orden. Priorizar. Rediseñar un proceso. Resolver deuda acumulada. O decidir internamente cómo queréis utilizar Salesforce.

El objetivo no es cambiar de proveedor. El objetivo es conseguir que Salesforce vuelva a acompañar al negocio.