Sus clientes llaman para preguntar dónde está el pedido, para pedir una factura o para avisar que algo llegó mal. Cada llamada termina en alguien del equipo buscando en el CRM un dato que el cliente podría consultar solo.
Para eso existe Experience Cloud, la herramienta de Salesforce para armar portales donde cada cliente ve lo suyo y resuelve sus gestiones. En esta guía les mostramos cómo construir un portal de clientes paso a paso, desde el site hasta un agente de Agentforce adentro.
El recorrido sale de la segunda parte de la Masterclass de Experience Cloud de Vantegrate, que se dio el 15 de octubre con Juan Manuel Garrido, Josué Mendoza y Francisco Morales conectado desde Europa. Josué armó el portal en vivo, y acá tienen todo ordenado para replicarlo en su org.
Experience Cloud, Self Service y la ensalada de nombres
Antes de la demo, JuanMa propuso un repaso de cómo se llamó este producto a lo largo del tiempo. La lista sorprende hasta a quienes trabajan con Salesforce hace años.
Desde Salesforce Communities hasta Self Service, este producto ha cambiado de nombre varias veces. Sin embargo, su funcionalidad para crear portales personalizados es más robusta que nunca.
Arrancó como Salesforce Communities.
Después llegó el famoso Community Cloud, con el que lo conoció la mayor parte del mercado.
Más tarde pasó a ser Experience Cloud, el nombre que todavía usa casi todo el ecosistema.
Durante menos de un año, entre un Dreamforce y el siguiente, se llamó Agentforce Service.
Hoy se llama Self Service, a secas.
Josué contó que uno de sus primeros proyectos fue justamente con Community Cloud. Y en la clase todos siguieron diciendo Experience Cloud, porque es como lo busca y lo reconoce la mayoría de los equipos.
Por qué conviene mirar la funcionalidad y no la marca
Fran comentó que, por lo que leyó, por detrás el producto es el mismo. JuanMa sumó su hipótesis: los nombres nuevos se perciben como innovación continua, sobre todo entre inversores que no conocen la plataforma en detalle.
Para quien se está preparando para una certificación, el cambio constante de nombres es una complicación real. Por eso conviene entender los conceptos de fondo, que son los que se mantienen.
Qué es Experience Cloud hoy
En sus orígenes eran comunidades, en plena época de redes sociales. La idea era colaborar: alguien creaba un registro, otros comentaban y se armaba una especie de foro.
Después Salesforce entendió que con la misma base se podían construir sitios web, portales y aplicaciones. Por eso el producto pasó a hablar de experiencias.
Para JuanMa, el nombre Self Service se queda corto. El producto ofrece mucha más potencia que un portal de autogestión, aunque ese sea uno de sus usos más frecuentes.
La analogía del home banking
Josué lo explicó con una imagen muy clara. Salesforce es todo el banco y Experience Cloud es su home banking.
Cuando entran a su home banking, ven sus cuentas, sus tarjetas y sus deudas. No ven las de nadie más, y ese es exactamente el objetivo de un portal de clientes.
El caso Andina: un distribuidor que vive en el teléfono
Para la demo, Josué inventó a Andina, un distribuidor B2B que vende a comercios de toda la región y gestiona todo en Salesforce. El nombre fue al azar, aunque JuanMa recordó que existe una empresa homónima con un caso de éxito real de Agentforce.
El problema de Andina es conocido: los clientes llaman todo el tiempo para preguntar por su pedido, su factura o un envío que llegó mal. El equipo de atención tiene la información en el CRM, pero pasa el día repitiendo los mismos datos por teléfono.
La propuesta fue un portal donde cada cliente vea sus datos, abra sus casos y resuelva sus gestiones.
Menos llamadas, menos mails y menos casos cargados a mano.
Si su empresa está en distribución mayorista o en otra de las industrias con venta B2B, este escenario les va a resultar familiar.
Los pasos del portal
Josué planteó la implementación en seis pasos, una secuencia que sirve también para proyectos reales. Los grandes bloques son estos:
Crear el site.
Asignar usuarios.
Proteger la seguridad de los datos.
Extender la funcionalidad con Flows y Lightning Web Components.
Sumar Agentforce como bonus final.
La idea es que cada etapa deje el portal un paso más cerca de producción. En la org de demo había una cuenta, Almacén El Roble, con dos contactos (María López y Pedro Ruiz) y una vista de pedidos totalmente estándar.
Crear el site y armar las páginas
Antes de crear nada hay dos requisitos previos. Tienen que activar Experience Cloud en la org y tener un dominio registrado para la organización, porque todos los sites van a colgar de ese dominio.
Con eso listo, en Setup aparece la lista de sites y la opción de crear uno nuevo. Salesforce ofrece varias plantillas, con distintos estilos visuales y distintos motores por detrás: algunas trabajan con componentes Lightning y otras más nuevas permiten tecnologías como React.
La recomendación es elegir la plantilla según el caso de uso. Un foro, un sitio público y un portal privado de clientes no necesitan lo mismo.
El Builder: como armar una landing page
Una vez creado el site, se trabaja en el Builder. La experiencia es muy parecida a armar una landing page: se arrastran componentes, se configuran y se ve el resultado en el momento.
Josué sumó un banner, un botón que podía redirigir a un portal de ayuda con artículos y una lista de registros de cuentas. Ese componente hereda las list views del CRM, como "My Accounts", así que no hay que reconstruir nada.
Hay muchísimos componentes estándar y también se pueden usar componentes custom. Desde la configuración del tema se cambian colores, logos y branding, y con CSS se puede llegar a un portal que ni parece Salesforce.
Publicar y probar
Cuando la vista está lista, se hace clic en Publish. El sitio queda disponible en el dominio de la org, y los usuarios entran con su propio login.
Un buen hábito es probar siempre desde una ventana de incógnito. Así ven el portal como lo va a ver el cliente y no con su sesión de administrador.
Habilitar cuentas y contactos como usuarios del portal
Con la parte visual armada, la pregunta pasa a ser quién entra al portal y qué ve adentro. El orden importa: primero se habilita la cuenta y después los contactos.
En la cuenta hay que agregar al page layout el botón Enable as Partner. Al usarlo, esa cuenta queda habilitada para que su gente pueda ingresar al site.
Después, desde cada contacto, se lo habilita como usuario del portal y se le asigna una licencia. En la demo, María quedó como usuaria con el perfil Customer Community Plus User.
Configurar con Cursor y las skills de Salesforce
Un detalle que despertó preguntas: Josué hizo buena parte de esta configuración sin clics. Trabajó con Cursor y las skills de Salesforce, pidiéndole al agente que habilitara la cuenta como partner y los contactos como usuarios.
Si su equipo ya trabaja así, vale la pena explorar las herramientas de Salesforce para desarrolladores.
Qué hacer cuando son cientos de usuarios
JuanMa preguntó cómo se escala esto cuando llegan muchos usuarios como María. La respuesta de Josué fue directa: con un script.
Puede ser en Apex o en cualquier lenguaje que se conecte a Salesforce, como Python. De hecho, el acceso de María y de Pedro en la demo se habilitó por script.
La seguridad va primero
Este es el paso que no se puede saltear. Antes de mostrar un solo dato, hay que definir qué puede ver cada usuario externo.
La seguridad es crucial al construir un portal de clientes. Define qué puede ver cada usuario externo y aplica las mejores prácticas para proteger los datos de tu empresa.
Todo arranca en Sharing Settings, donde además del acceso interno se define el acceso por defecto para usuarios externos. La buena práctica de Josué es una sola: acceso externo siempre privado.
En el cierre, Josué lo marcó como una de las malas prácticas más comunes. Dejar el acceso externo como público no corresponde en un portal de clientes.
Sharing sets: abrir solo lo necesario
Con todo privado, se abre lo justo con sharing sets (conjuntos de colaboración). Josué creó uno llamado Clientes con dos reglas:
Si la cuenta del usuario coincide con la cuenta del caso, puede leer ese caso.
Si la cuenta del pedido coincide con la cuenta del usuario, puede ver ese pedido.
El resultado se vio en vivo. María entró al portal, abrió la vista de cuentas y solo vio Almacén El Roble, la cuenta a la que pertenece.
Ojo con los cambios de seguridad para guest users
Josué contó que Salesforce ajustó la seguridad para los guest users y usuarios de portales. Según comentaron, el cambio se había anunciado con tiempo, pero cuando llegó el release muchos administradores tuvieron problemas.
El mensaje fue simple: lean las notas de cada release antes de que llegue a producción. Si quieren profundizar en este enfoque, revisen cómo trabajamos la seguridad de la plataforma y la transparencia de datos.
Una misma página para distintas audiencias
Otra pregunta fue si hace falta tocar permisos dentro del Builder. Además de las configuraciones de visibilidad del contenido, se pueden crear distintas versiones de una misma página según la audiencia.
Por ejemplo, los clientes pueden ver una lista de cuentas en la home. Los socios, en cambio, podrían ver un mini dashboard con pedidos entregados, devueltos y cantidad de reclamos.
Extender el portal con Flows y Lightning Web Components
Con usuarios y seguridad resueltos, llega el momento de que el portal haga algo útil. El objetivo era que María pudiera crear un reclamo sin llamar a nadie.
Josué creó una página nueva llamada Reclamos y le sumó un Flow de pantalla. El formulario arranca con un simple "Contanos qué pasó" y genera el registro en Salesforce.
En la misma página agregó un Lightning Web Component con la lista de pedidos del cliente. Publicó, entró como María y los dos componentes funcionaron.
Flow o componente: cuándo usar cada uno
La regla que dejó Josué es práctica. Si lo pueden resolver con un Flow, usen un Flow, y reserven el Lightning Web Component para cuando la funcionalidad se complica.
Lo más importante es que ambos respetan toda la visibilidad de registros configurada en el CRM. No se expone nada que los sharing sets no permitan.
Bonus: Agentforce dentro del portal
El bonus fue sumar un agente. En la demo, el agente quedó disponible en todas las páginas del portal, sin importar por dónde navegara el usuario.
Por detrás hay un agente de Agentforce con Omni-Channel conectado, para derivar la conversación a personas o a otros agentes. El agente de Andina era simple: solo respondía sobre pedidos.
Ante una consulta fuera de su alcance, contestó "No puedo ayudarte con esta solicitud".
Si están evaluando agentes de IA para atención al cliente, el portal es uno de los lugares más naturales para empezar.
Cómo se configura
Al exponer un agente, Salesforce crea automáticamente otro site que se limita a contener al agente. Ese site es el que después se conecta con el portal principal.
La conexión se hace con un pequeño script en el head markup del portal. Lleva tres parámetros: el ID del despliegue (Josué creyó recordar que es el de Omni-Channel), el nombre del agente y la URL del site donde está alojado.
Si el ruteo de Omni-Channel no está configurado, el chat muestra que no hay agentes disponibles. Esa parte quedó como posible tema para una tercera Masterclass.
Con o sin login
Desde el chat preguntaron si el agente funciona para usuarios que no iniciaron sesión. Josué confirmó que sí, porque ya lo había hecho para una demo en otro proyecto.
El disclaimer de los permisos
Josué fue honesto: para llegar con todo funcionando a la clase, le dio superpoderes al agente para que pudiera ver todo. En producción, eso es exactamente lo que no hay que hacer.
La recomendación es mucho cuidado con los permisos que recibe el agente. Tiene que ver lo mismo que vería el usuario y nada más.
Un chat como única interfaz
Fran sumó una idea para pensar. Si la interfaz de una aplicación es muy compleja, ¿por qué no una aplicación cuya única interfaz sea un chat?
Aclaró que no sabe si lo haría con Experience Cloud. Pero el concepto abre una conversación interesante sobre cómo van a interactuar los clientes con los sistemas.
Más allá de Agentforce: Sellium
JuanMa recordó que la capa de autoservicio se puede enriquecer con IA de dos maneras. Una es Agentforce, nativo de Salesforce, y la otra es Sellium, el producto de Vantegrate.
Sellium conecta un agente desde una org de Salesforce, un experience site o un sitio web. También funciona en WhatsApp, Instagram, TikTok, Facebook o correo electrónico, y es compatible con Salesforce y con otros ecosistemas.
El resultado: de las llamadas al autoservicio
Así cerró Josué la demo. Antes, Andina tenía consultas por teléfono, casos creados a mano y a todo el equipo de atención dedicado a eso.
Ahora hay un portal donde el cliente crea sus reclamos, los sigue y consulta sus pedidos. Y un agente que responde sin que nadie levante el teléfono.
Si quieren llevar Experience Cloud y Agentforce a su org, conozcan nuestra experiencia con Salesforce y al equipo de Vantegrate. La primera parte de esta Masterclass está en el canal de YouTube de Vantegrate y sigue vigente.
En Vantegrate Pulse publicamos guías de cada clase y en recursos hay material descargable. Y si prefieren que los acompañemos en la implementación, pueden agendar una demo.
Preguntas frecuentes
¿Experience Cloud y Self Service son lo mismo?
Sí. Self Service es el nombre actual del producto que antes se llamó Communities, Community Cloud, Experience Cloud y Agentforce Service, y por detrás la herramienta es la misma.
¿Qué se necesita antes de crear un portal en Experience Cloud?
Hay que activar Experience Cloud en la org y tener un dominio registrado para la organización. Después se elige la plantilla según el caso de uso y se arman las páginas en el Builder.
¿Cómo se da acceso a los clientes al portal?
Primero se habilita la cuenta con el botón Enable as Partner. Después cada contacto se convierte en usuario del portal con su licencia, por ejemplo con el perfil Customer Community Plus User.
¿Cómo evitar que un cliente vea datos de otro?
Definiendo el acceso externo como privado en Sharing Settings y abriendo solo lo necesario con sharing sets. Así cada usuario ve únicamente los casos y pedidos de su propia cuenta.
¿Se puede agregar un agente de Agentforce a un portal de Experience Cloud?
Sí. Se agrega con un pequeño script en el head markup del portal y conviene tener configurado Omni-Channel para derivar a personas, cuidando que el agente tenga solo los permisos necesarios.
