Por Thiago Schmitz | Enterprise Architect for Salesforce Core en Cloudgaia
Tabla de contenidos
- Agentforce Voice no es simplemente un voice bot
- De entender una pregunta a ejecutar un proceso
- El canal cambia, pero Agentforce sigue siendo Agentforce
- Diseñar para voz requiere pensar diferente
- Los pequeños detalles técnicos tienen un impacto enorme
- La voz de la marca ahora puede ser literalmente una voz
- Mobile puede llevar Agentforce a momentos donde una pantalla no funciona
- La próxima interfaz puede no parecer una interfaz
- Aspectos clave
- Q&A: algunas preguntas que las organizaciones deberían hacerse
En mis años trabajando con arquitecturas Salesforce, vi cómo la forma en la que los usuarios interactúan con los sistemas cambió varias veces. Pasamos de interfaces complejas y altamente estructuradas a experiencias móviles, portales de autoservicio y, más recientemente, agentes capaces de interpretar lenguaje natural.
Sin embargo, la mayoría de esas experiencias todavía parten de una misma premisa: el usuario se encuentra frente a una pantalla.
Con Agentforce Voice, Salesforce empieza a cuestionar esa premisa.
Aun así, el cambio más interesante no es simplemente que Agentforce ahora pueda hablar. La verdadera evolución es que una conversación de voz puede convertirse en un punto de acceso directo a los datos, las acciones y los procesos que ya existen dentro del ecosistema Salesforce de forma inteligente.
Desde una perspectiva de arquitectura, esto abre una discusión mucho más amplia sobre cómo deberíamos diseñar las próximas experiencias empresariales.
Agentforce Voice no es simplemente un voice bot
Cuando escuchamos hablar de AI aplicada a voz, es fácil pensar en una versión más avanzada de los voice bots o de los sistemas IVR que las empresas utilizan desde hace años, pero Agentforce Voice parte de una arquitectura diferente.
Salesforce define a Agentforce Voice como una capacidad que permite a los agentes comprender conversaciones habladas, interpretar la intención del usuario y ejecutar acciones para resolver una solicitud.
El agente puede apoyarse en datos del CRM, Flows, APIs y las mismas capacidades que ya utiliza Agentforce en otros canales.
El mismo agente diseñado en Agentforce Builder puede utilizar subagentes, acciones y datos existentes y extender esas capacidades a experiencias de voz.
Salesforce resume esta idea con un principio muy claro: construir un agente y desplegarlo en múltiples canales.
Durante mucho tiempo, las empresas construyeron soluciones diferentes para cada canal. El resultado suele ser una arquitectura con lógica duplicada, experiencias inconsistentes y múltiples puntos de mantenimiento.
Agentforce propone otra dirección. Primero diseñamos las capacidades del agente y después decidimos dónde tiene sentido exponerlas.
De entender una pregunta a ejecutar un proceso
La segunda diferencia importante aparece cuando analizamos qué ocurre después de que el agente entiende al usuario.
El cambio más importante no está solamente en comprender mejor lo que el cliente necesita, sino en poder actuar sobre esa necesidad en tiempo real.
Por ejemplo, un cliente podría consultar el estado de un pedido y Agentforce Voice podría identificarlo, acceder a la información correspondiente en Salesforce, actualizar un registro o crear un caso sin obligarlo a navegar por múltiples opciones.
| Antes: IVR tradicional | Ahora: Agentforce Voice |
| La interacción sigue una estructura rígida y previamente definida. | La conversación se adapta a lo que el usuario necesita en cada momento. |
| El usuario debe navegar opciones como “presione uno para ventas” o “dos para soporte” y reconocer comandos específicos (menús, pasos y rutas preconfiguradas) | El usuario expresa su necesidad directamente, utilizando lenguaje natural. El agente interpreta intención, información, contexto, sentimiento y determina dinámicamente cómo continuar. |
| El sistema suele limitarse a dirigir la llamada o brindar información básica. | Agentforce puede consultar información en Salesforce y ejecutar acciones y procesos de negocio. |
| Para completar una gestión, generalmente es necesario derivar la interacción a una persona. | El agente puede actualizar registros, crear casos, ejecutar workflows o iniciar otros procesos. |
Por eso, la primera pregunta no debería ser “¿Qué conversación queremos automatizar?”, sino “¿Qué proceso queremos que el usuario pueda resolver mediante una conversación?”
La diferencia parece pequeña, pero cambia completamente el diseño del agente.
El canal cambia, pero Agentforce sigue siendo Agentforce
En la última sesión de TDX, Andrew Mangano resume uno de los puntos centrales de la sesión con una frase muy clara: “Agentforce is Agentforce is Agentforce”.
La idea es simple: el agente no debería definirse por el canal en el que aparece.
En la demo, el equipo construye y prueba un agente en Agentforce Builder y después despliega una experiencia de voz dentro de una aplicación móvil utilizando Agentforce Mobile SDK.
Más adelante, muestran un escenario dentro de Salesforce Mobile donde un empleado consulta información sobre una cuenta y sus oportunidades utilizando su voz. Son experiencias distintas, pero la capacidad del agente sigue viniendo de Agentforce.
Este enfoque puede tener un impacto importante en la arquitectura empresarial. En lugar de pensar en un agente para cada interfaz, podemos diseñar agentes que concentren capacidades de negocio y después evaluar cómo presentarlas en cada canal.
Eso no significa que la experiencia deba ser exactamente igual en todos los lugares. De hecho, es ahí donde aparece uno de los principales desafíos de Voice.
Aspectos clave
|
Diseñar para voz requiere pensar diferente
Uno de los puntos que más me interesó de la sesión fue el foco de Salesforce en las buenas prácticas de diseño.
Reutilizar las capacidades de un agente no significa copiar una experiencia de chat y agregarle audio. Leer y escuchar son experiencias diferentes.
En una pantalla podemos recorrer un texto o buscar visualmente la información que necesitamos. En una conversación de voz, el usuario recibe la información de manera secuencial y en tiempo real.
Por eso, una respuesta que funciona en chat puede no funcionar cuando alguien tiene que escucharla.
Salesforce recomienda utilizar mensajes de bienvenida breves y mantener las respuestas concretas para que la conversación avance de forma natural.
La latencia también se vuelve crítica.
En una experiencia visual, un usuario puede tolerar cierto tiempo de carga. En una conversación, cada silencio se siente. Una acción Apex, un Flow, un prompt o una integración lenta puede interrumpir completamente el ritmo de la interacción.
Diseñar Agentforce Voice también implica revisar la performance de las acciones disponibles para el agente.
No alcanza con que una acción funcione. Tiene que funcionar al ritmo de una conversación.
Los pequeños detalles técnicos tienen un impacto enorme
Hay otro aspecto de Voice que me parece particularmente interesante desde la arquitectura: detalles que antes parecían menores pasan a ser parte central de la experiencia. La pronunciación es un buen ejemplo.
Todas las organizaciones tienen nombres de productos, acrónimos y términos específicos de su industria. Durante la sesión, Salesforce muestra cómo utilizar diccionarios de pronunciación y keyword boosting para ayudar al agente a interpretar correctamente esos conceptos.
Si el sistema interpreta mal una sigla, el problema no es solamente de pronunciación. El agente puede terminar buscando información equivocada.
Lo mismo ocurre con la manera en la que presentamos los datos.
Una fecha, un monto o un número de caso pueden estar correctamente almacenados y, aun así, no sonar naturales cuando el agente los verbaliza.
En Voice, el formato de salida deja de ser solamente una decisión técnica. También es una decisión de experiencia.
La voz de la marca ahora puede ser literalmente una voz
Durante años hablamos de “brand voice” para definir el tono, las palabras y la personalidad con las que una empresa se comunica.
Agentforce Voice hace que ese concepto sea bastante más literal.
Salesforce permite seleccionar diferentes voces y configurar características de la experiencia. En la demo de TDX, también vemos controles relacionados con velocidad, similitud y estabilidad.
Esto plantea preguntas nuevas: ¿Qué voz representa mejor a una organización? ¿La misma voz debería utilizarse para todos los casos de uso? ¿Una experiencia de soporte necesita el mismo tono que un agente interno para empleados?
No creo que estas decisiones deban quedar exclusivamente en manos de tecnología.
La arquitectura define las capacidades del agente, el negocio define el proceso, marketing entiende la identidad de la marca y los equipos de experiencia entienden al usuario.
Voice es uno de esos escenarios donde todas esas disciplinas necesitan trabajar juntas.
Mobile puede llevar Agentforce a momentos donde una pantalla no funciona
La segunda parte de la sesión de TDX se concentra en Agentforce Voice para aplicaciones móviles.
En la demo, Salesforce integra un agente dentro de una aplicación utilizando Agentforce Mobile SDK. El usuario puede hablar o escribirle al mismo agente manteniendo el contexto de la conversación.
Como arquitecto, inmediatamente pienso en escenarios como un técnico trabajando en campo, un vendedor viajando entre clientes o una persona que necesita consultar información mientras realiza otra tarea.
Durante años intentamos mejorar estos procesos construyendo mejores interfaces móviles. Simplificamos formularios, reducimos campos y diseñamos experiencias con menos clics.
Tal vez, en algunos casos, la mejor solución sea eliminar los clics.
Eso no significa que Voice reemplazará las aplicaciones móviles. Significa que tenemos una nueva modalidad para procesos donde utilizar una pantalla genera fricción.
La próxima interfaz puede no parecer una interfaz
Creo que Agentforce Voice es interesante porque nos obliga a revisar algo que los arquitectos muchas veces damos por sentado.
Durante décadas diseñamos sistemas esperando que las personas aprendieran a utilizarlos. Creamos pantallas, botones, menús y formularios. Después capacitamos a los usuarios para que entendieran cómo interactuar con esa estructura.
La IA está empezando a invertir esa relación.
Ahora tenemos sistemas capaces de comprender mejor la forma en la que las personas ya se comunican. Agentforce Voice lleva esa idea a la conversación hablada y conecta esa interacción con datos y acciones dentro de Salesforce.
No creo que las pantallas vayan a desaparecer. Sí creo que, como arquitectos, deberíamos dejar de asumir que siempre son el punto de partida.
Antes de diseñar la próxima interfaz, tal vez valga la pena hacerse una pregunta mucho más simple: ¿El usuario realmente necesita una pantalla para resolver esto?
Para las organizaciones que buscan desplegar Agentforce atención al cliente respetando gobernanza, voz de marca y realidad operativa, el camino no es solo técnico. Es una pregunta de delivery, y esa es la conversación que en Cloudgaia tenemos todos los días con nuestros clientes.
Q&A: algunas preguntas que las organizaciones deberían hacerse
¿Agentforce Voice reemplaza los canales digitales existentes?
No. Voice debería entenderse como otra modalidad dentro de una estrategia de agentes multicanal. La web, el chat y las aplicaciones móviles continúan siendo fundamentales para muchos procesos.
La pregunta es dónde una interacción hablada ofrece una experiencia más natural.
¿Todos los agentes de Agentforce deberían tener Voice?
Definitivamente no.
Voice tiene sentido cuando el caso de uso es conversacional y cuando hablar reduce la fricción del proceso.
Agregar voz a un proceso que necesita comparar veinte datos en una pantalla probablemente no mejore la experiencia.
¿Agentforce Voice reemplaza a los agentes humanos?
No creo que esa sea la discusión correcta. Hay interacciones repetitivas que un agente puede resolver de manera autónoma. También existen conversaciones complejas o sensibles que requieren contexto humano, criterio y empatía.
El verdadero desafío está en diseñar correctamente dónde actúa Agentforce y cuándo debe ocurrir una escalación.
¿Qué debería revisar una empresa antes de implementar Voice?
Yo empezaría por cuatro puntos: procesos, datos, acciones y performance.
El agente necesita entender qué proceso debe resolver. Necesita acceso al contexto correcto. Sus acciones tienen que estar claramente definidas y toda la arquitectura debe responder con una latencia adecuada para una conversación.
La tecnología de voz es solamente una parte de la solución.
