En este artículo
Lo importante en 30 segundos
- No es un producto ni un SKU: es una arquitectura y un término paraguas de Salesforce.
- No retira la interfaz: deja de exigir que toda interacción ocurra dentro de ella.
- No arregla un proceso confuso ni un dato poco fiable; los deja más a la vista.
Si utilizas Salesforce, es probable que hayas empezado a encontrarte Headless 360 en presentaciones, eventos o conversaciones sobre agentes de inteligencia artificial. El nombre puede hacer pensar que Salesforce ha lanzado otro producto que hay que evaluar o implantar.
Headless 360 no es un nuevo Salesforce ni un producto que tengas que implantar. Es la arquitectura con la que Salesforce quiere que sus datos, procesos y reglas puedan utilizarse también desde agentes y otras aplicaciones, sin obligar a una persona a trabajar siempre desde la interfaz de Salesforce.
Si ya utilizas Salesforce, la pregunta útil no es «¿necesitamos Headless 360?». Es otra: ¿qué tareas tendría sentido resolver de otra forma y está nuestro Salesforce preparado para ello?
¿Qué significa Headless 360 en la práctica?
Pensemos en una situación bastante habitual. Se acerca la reunión de forecast y hay oportunidades que llevan días sin actualizar. Alguien pide al equipo que revise fechas de cierre, importes y siguientes pasos.
Los usuarios entran en Salesforce, buscan sus oportunidades y actualizan lo necesario. Ahora imagina otra forma de hacer una de esas tareas: un agente detecta que una oportunidad debería cerrar este mes pero lleva tres semanas sin actividad, y pregunta.
Esta oportunidad sigue prevista para septiembre. ¿Mantienes la fecha de cierre?
El usuario responde y Salesforce se actualiza. La oportunidad sigue estando en Salesforce, el pipeline sigue estando en Salesforce y las reglas del proceso siguen estando en Salesforce. Lo que ha cambiado es el lugar desde el que la persona ha realizado esa acción.
Esa es una forma sencilla de entender Headless 360: Salesforce puede seguir haciendo el trabajo por detrás aunque el usuario no tenga su pantalla abierta.
¿Headless 360 significa dejar de utilizar la interfaz de Salesforce?
No. Hay trabajos para los que seguir entrando en Salesforce tiene todo el sentido, y es justo donde una interfaz completa aporta valor.
Revisar una cuenta con varias oportunidades, contactos, actividad e incidencias
Analizar el pipeline de un equipo
Gestionar un caso que necesita mucho contexto
Comparar resultados o preparar una decisión
Pero piensa ahora en otro tipo de tareas:
Confirmar una fecha
Actualizar un siguiente paso
Consultar el estado de una oportunidad
Saber si un cliente tiene incidencias abiertas
Recibir un resumen antes de una reunión
Aprobar una acción sencilla
¿Hace falta entrar en Salesforce, localizar el registro y navegar por distintas pantallas para cada una de ellas? No necesariamente.
Headless 360 abre la posibilidad de que determinadas interacciones ocurran desde otros entornos mientras Salesforce sigue gestionando lo que hay detrás. No todo lo que utiliza Salesforce tiene que ocurrir dentro de la pantalla de Salesforce.
Salesforce ya se conectaba con otros sistemas: ¿qué hay de nuevo?
Las empresas llevan años montando integraciones de Salesforce con otros sistemas: ERP, ecommerce, aplicaciones propias y muchas otras herramientas. Y las APIs tampoco aparecieron con Headless 360. Sería exagerado decir que hasta ahora Salesforce solo podía utilizarse desde su propia interfaz.
Lo que cambia es la importancia que adquiere esa separación con la llegada de los agentes.
Una persona abre Salesforce, busca una oportunidad, interpreta la pantalla y decide qué hacer. Un agente trabaja de otra forma: necesita consultar información, entender determinadas reglas y ejecutar una acción sin recorrer una pantalla como lo haría una persona.
Salesforce está llevando su plataforma hacia un modelo en el que esas capacidades puedan utilizarse desde distintos agentes, aplicaciones y experiencias. Y lo plantea reutilizando los datos, la metadata, los permisos y la lógica que ya existen en tu instalación, no montando un sistema paralelo.
La tecnología que lo hace posible importa a quien tenga que construirla. Para el negocio hay una pregunta anterior: ¿dónde está hoy la fricción entre Salesforce y la forma real de trabajar?
¿Cómo saber si Headless 360 puede ser relevante para tu empresa?
No todos los problemas con Salesforce se resuelven sacando tareas de su interfaz, y no todas las empresas necesitan cambiar la forma en la que sus usuarios trabajan. Esta tabla permite hacer una primera separación.
| Situación hoy | Relevancia | Qué revisar primero |
|---|---|---|
| Se entra solo para actualizaciones muy sencillas | Puede serlo | Qué acciones generan fricción y con qué frecuencia |
| El equipo trabaja en otras herramientas y actualiza tarde | Puede serlo | Qué información llega tarde y por qué |
| Una aplicación propia necesita procesos de Salesforce | Puede serlo | Qué datos, acciones y reglas necesita usar |
| Queremos que agentes consulten o ejecuten procesos | Puede serlo | Datos, permisos, reglas y procesos implicados |
| Salesforce no refleja el proceso real del negocio | No es lo primero | El proceso y la configuración actuales |
| El forecast no es fiable | Depende | Si el origen es fricción, proceso, dato o adopción |
| Los datos de Salesforce no son fiables | No es el punto de partida | Calidad y gobierno del dato |
| Los usuarios necesitan mucho contexto para decidir | Puede que no | Si la interfaz actual ya presenta bien ese contexto |
La diferencia entre unas filas y otras es lo importante.
¿El problema está en la interfaz o en el Salesforce que hay detrás?
Esta es probablemente la comprobación más útil. Volvamos al ejemplo del forecast: el equipo no mantiene las oportunidades actualizadas. Eso puede significar cosas muy diferentes.
Caso 1. Actualizar un dato sencillo exige demasiado trabajo
El proceso está claro y los usuarios saben qué información tienen que mantener. Pero cambiar una fecha o confirmar un siguiente paso obliga a abrir Salesforce, localizar la oportunidad y recorrer varias pantallas.
Aquí puede existir una oportunidad para simplificar la interacción. El proceso quizá no necesita cambiar; la forma de acceder a él, sí.
Caso 2. Nadie tiene claro qué debe actualizar
Las fases comerciales no están bien definidas y cada persona interpreta una oportunidad de forma distinta. Las fechas de cierre significan cosas diferentes según quién las introduzca, y hay campos obligatorios que nadie sabe por qué lo son.
Aquí Headless 360 no es la solución. Hacer más fácil la actualización de un proceso confuso no hace que el proceso deje de ser confuso. Primero hay que revisar el Salesforce existente.
Caso 3. Los datos no son fiables
El problema tampoco está en la interfaz. Si hay duplicados, información incompleta o datos distintos según el sistema que se consulte, permitir que un agente acceda a Salesforce no mejora el resultado por sí solo.
Un agente puede obtener una respuesta más rápido. Eso no garantiza que la respuesta sea buena.
Caso 4. La interfaz actual funciona bien
También es una conclusión perfectamente válida. No hay que sacar tareas de Salesforce simplemente porque ahora existan más posibilidades de hacerlo.
Si el equipo trabaja bien en Salesforce, encuentra el contexto que necesita y el proceso es eficiente, quizá no haya nada que cambiar. Headless 360 abre una posibilidad; no crea por sí solo una necesidad.
¿Qué deberías revisar antes de pensar en Headless 360?
Antes de hablar de agentes o de arquitectura, conviene mirar cómo trabajan realmente los equipos. Son cinco comprobaciones.
1. ¿Para qué tareas entran hoy en Salesforce?
No pienses en procesos completos, piensa en acciones: consultar un dato, actualizar una fecha, registrar una actividad, aprobar algo, preparar una reunión, revisar una incidencia.
Después pregunta: ¿cuáles de esas acciones necesitan realmente una pantalla completa?
2. ¿Qué trabajo importante sigue ocurriendo fuera de Salesforce?
Excel, correo, Teams, Slack, aplicaciones internas. Trabajar fuera de Salesforce no es automáticamente un problema.
La señal aparece cuando información necesaria para el proceso se queda fuera y después alguien tiene que copiarla, reconstruirla o perseguir a otras personas para introducirla.
3. ¿Por qué aparece la fricción?
Decir «los usuarios no utilizan Salesforce» explica muy poco. Hay que bajar un nivel.
¿Hay demasiados pasos para hacer algo sencillo?
¿Se pide información que después nadie utiliza?
¿Falta el contexto necesario para decidir?
¿El proceso configurado no coincide con el proceso real?
¿La tarea debería hacerse desde la herramienta en la que esa persona ya trabaja?
Según la respuesta, la solución será distinta.
4. ¿Puedes confiar en lo que hay detrás?
Imagina que un agente pregunta qué oportunidades están en riesgo. ¿Las fases están actualizadas? ¿Las fechas de cierre significan lo mismo para todo el equipo y hay un siguiente paso real?
Imagina que prepara el contexto de un cliente. ¿Los datos están completos? ¿Las incidencias están bien relacionadas y la información importante está de verdad en Salesforce?
Headless 360 hace que estas preguntas sean más importantes, no menos.
5. ¿Qué debería seguir ocurriendo dentro de Salesforce?
No todo tiene que convertirse en una conversación con un agente. Hay trabajos que requieren contexto, análisis y comparación, y ahí una interfaz completa puede seguir siendo la mejor solución.
El ejercicio no consiste en conseguir que los usuarios vean menos Salesforce. Consiste en decidir qué forma de interacción tiene sentido para cada trabajo.
¿Puede Headless 360 solucionar un problema de adopción?
Puede reducir determinadas fricciones, pero no sustituye el trabajo que exige un problema de adopción de Salesforce.
Imagina que actualizar un siguiente paso requiere demasiados clics. Permitir hacerlo de una forma más sencilla puede ayudar.
Ahora imagina otro escenario. Los usuarios no actualizan las oportunidades porque el pipeline no representa cómo venden, porque introducen información que después nadie utiliza o porque Salesforce se ha convertido en la herramienta para preparar el informe de Dirección y no en algo que les ayude a trabajar.
El problema ya no es la pantalla. Cambiar el lugar desde el que se introduce un dato no soluciona la causa.
Entonces, ¿hay que hacer algo ahora?
No necesariamente. Que Salesforce esté dando visibilidad a Headless 360 no significa que todas las empresas que ya lo utilizan necesiten arrancar un proyecto.
El primer paso puede ser mucho más sencillo: observar dónde existe hoy fricción, qué tareas obligan a cambiar constantemente de herramienta, qué información llega tarde y qué acciones son innecesariamente pesadas. Y cuáles de esos problemas se deben realmente a la interfaz.
Puedes terminar con tres conclusiones distintas.
- 01
La forma actual de trabajar funciona y no existe una razón para cambiarla.
- 02
Algunas interacciones podrían simplificarse sin rediseñar todo el proceso.
- 03
El problema no es Headless 360: el Salesforce que ya está en producción necesita cambiar.
En ese último caso tiene más sentido empezar por evolucionar un Salesforce que ya está en producción que por añadir una nueva forma de interactuar con él.
¿Qué cambia realmente con Headless 360?
Headless 360 cambia una suposición que durante años ha sido bastante natural: utilizar Salesforce y utilizar la interfaz de Salesforce no tienen por qué ser exactamente lo mismo.
Salesforce puede seguir siendo el lugar donde viven los datos, los procesos, los permisos y las reglas aunque determinadas interacciones ocurran desde otra aplicación o mediante un agente.
Para algunas empresas esto abrirá formas interesantes de reducir trabajo administrativo. Para otras será poco relevante a corto plazo. Y en muchas pondrá encima de la mesa un problema anterior: procesos que ya no reflejan el negocio, datos poco fiables o una adopción que sigue dependiendo de perseguir a los usuarios.
Por eso la pregunta útil no es «¿necesitamos Headless 360?». Es esta: ¿qué trabajo necesita realmente una pantalla y qué trabajo solo necesita que Salesforce haga bien su parte por detrás? Esa respuesta te dirá mucho mejor si hay algo que 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.