Agentforce Casey: qué es el nuevo agente de Salesforce para Customer Service

No es simplemente un chatbot que busca una respuesta.

Salesforce quiere que Casey pueda pasar de responder:

¿Dónde está mi pedido?

a actuar:

Comprueba el pedido, actualiza lo que corresponda o inicia el siguiente proceso para resolver la incidencia.

Ese cambio es importante.

Pero también cambia lo que tienes que exigirle a tu Salesforce.

Porque para que un agente resuelva una incidencia no basta con que sepa conversar.

Piensa en una incidencia relativamente normal.

Un cliente escribe porque una máquina sigue en garantía y necesita asistencia.

Para resolverla puede hacer falta saber:

• quién es el cliente

• qué producto tiene instalado

• cuándo lo compró

• qué garantía aplica

• si existe una incidencia previa

• qué técnico corresponde

• si hay una pieza pendiente

• qué dice el contrato

• qué acciones puede ejecutar Atención al Cliente

Responder con educación es la parte fácil.

Resolver el problema exige contexto.

Ahí es donde Casey resulta más interesante que el chatbot tradicional.

¿Qué es Agentforce Casey?

Casey es el nombre que Salesforce utiliza actualmente para su help agent especializado en Customer Service.

Forma parte de la cartera de agentes preparados para trabajos concretos que Salesforce presentó el 11 de septiembre de 2026, y que repasamos entera en Agentforce Hunter y los nuevos agentes de Salesforce. En ese anuncio aparece como «Casey, your help agent» y figura con disponibilidad general.

Casey está orientado a resolver solicitudes de cliente a través de canales como:

• voz

• SMS

• WhatsApp

• chat web

Salesforce incluye entre sus casos predefinidos:

• preguntas frecuentes

• devoluciones

• gestión de cuenta

• escalado a una persona

Y el Agentforce Help Agent sobre el que se basa trae de serie la gestión de casos, y se amplía con acciones relacionadas con procesos como:

• pedidos

• citas

• cuentas

La diferencia con un bot tradicional está en el verbo.

No solo responder.

Intentar resolver.

Si lo que buscas es la explicación general de qué es Agentforce y qué cambia según el rol que tengas, la desarrollamos en Agentforce explicado; si lo que estás valorando ya es el proyecto, el trabajo es el de implantar Agentforce sobre un Salesforce que ya está en marcha.

¿Casey es diferente del Agentforce Help Agent?

No deberías tratarlos como dos productos completamente independientes.

Salesforce presentó Agentforce Help Agent el 25 de junio de 2026 como un agente autónomo de Customer Service que funciona sobre la plataforma de Agentforce 360, con disponibilidad general anunciada para julio de 2026.

En septiembre, dentro de su nueva cartera de job-ready agents, Salesforce lo presenta como:

Casey, your help agent.

Y su página de autoservicio utiliza directamente Casey the help agent.

Por tanto, para entender el naming:

Es muy posible que durante un tiempo encuentres documentación utilizando ambos nombres.

No significa necesariamente que sean dos agentes distintos.

¿Qué puede hacer Casey en Customer Service?

Salesforce diseña Casey alrededor de una idea:

resolver la petición completa cuando sea posible.

No simplemente detectar una intención y enviar al cliente un artículo.

Imagina estos escenarios.

«¿Cuál es el estado de mi pedido?»

Un bot básico puede explicar dónde consultar pedidos.

Un agente con el contexto y las acciones adecuadas puede consultar el pedido concreto y devolver la información correspondiente.

«Quiero devolver este producto»

No basta con copiar la política de devoluciones.

Para resolver el caso puede necesitar:

• identificar el pedido

• comprobar si cumple las condiciones

• iniciar el proceso correspondiente

• actualizar información

• confirmar al cliente qué ocurrirá después

«Necesito cambiar una cita»

El agente puede necesitar consultar disponibilidad y ejecutar una acción de reprogramación.

«Necesito hablar con alguien»

Aquí la resolución correcta puede ser precisamente dejar de intentar resolver el problema automáticamente.

Salesforce plantea el escalado a una persona manteniendo el contexto de la conversación.

Eso también es resolver bien un caso.

El cambio importante: de responder preguntas a ejecutar acciones

Durante años, el autoservicio se ha apoyado mucho en una lógica sencilla:

cliente pregunta → buscador encuentra artículo → cliente intenta resolverlo

La IA mejoró la primera parte:

cliente pregunta → IA redacta una respuesta basada en Knowledge

Casey intenta añadir una tercera:

cliente pregunta → agente entiende → consulta contexto → ejecuta acciones → resuelve o escala

Ese último tramo es el más difícil.

Porque obliga a conectar la conversación con el proceso real.

¿De dónde obtiene Casey las respuestas?

Uno de los elementos centrales es Salesforce Knowledge.

Salesforce diseñó el Help Agent para anclarse en Knowledge y responder preguntas a partir de ahí.

Durante la configuración también admite otras fuentes: documentación que se añade al agente o el contenido de una web que se rastrea.

Eso resuelve parte del problema.

Pero tener Knowledge no significa automáticamente tener buen conocimiento.

Pregunta a cualquier responsable de Customer Service:

¿Tenemos un único artículo actualizado para cada procedimiento importante?

La respuesta no siempre será sí.

Puede haber:

• artículos duplicados

• instrucciones antiguas

• documentación contradictoria

• excepciones que solo conoce el equipo

• PDF fuera de Salesforce

• procedimientos escritos en Slack

• información que nunca se documentó

Un agente puede recuperar Knowledge más rápido que una persona.

También puede encontrar más rápido información que no debería seguir vigente.

¿Qué pasa si nuestro Knowledge no está bien mantenido?

Entonces probablemente tienes un problema anterior a Casey.

La pregunta no es solo:

¿Puede la IA entender nuestros artículos?

Es:

¿Representan esos artículos cómo debería resolverse hoy cada situación?

Por ejemplo.

Knowledge dice que una devolución requiere tres pasos.

El equipo realmente aplica cinco.

Dos están automatizados.

Uno depende del país.

Y otro requiere aprobación del responsable cuando el importe supera cierto límite.

Casey necesita algo más que el artículo.

Necesita conocer el proceso.

¿Puede Casey ejecutar acciones dentro de Salesforce?

Sí, y ese es precisamente uno de los puntos que diferencia el concepto de Help Agent de un sistema dedicado únicamente a contestar.

Salesforce indica que el Help Agent incorpora acciones preconfiguradas para determinadas tareas y puede ampliarse desde Agentforce Builder.

Entre los escenarios que Salesforce menciona aparecen:

• gestionar casos

• gestionar pedidos

• programar citas

• trabajar sobre información de cuenta

Pero esto introduce una decisión importante para cualquier empresa:

¿qué debería poder hacer Casey sin pedir permiso?

Consultar no es lo mismo que modificar

Hay diferentes niveles de autonomía.

Nivel 1: consultar

Por ejemplo:

¿Cuándo vence mi garantía?

Nivel 2: recomendar

Según las condiciones, este caso debería tramitarse como garantía.

Nivel 3: preparar una acción

He preparado la solicitud. ¿Quieres confirmarla?

Nivel 4: ejecutar

He abierto el caso y programado la visita.

Nivel 5: ejecutar una excepción

He autorizado una devolución fuera de política.

Estos niveles no deberían mezclarse.

El último probablemente exige unas reglas y controles muy diferentes al primero.

Por eso un proyecto de Agentforce para Service no empieza preguntando:

¿Qué sabe hacer Casey?

Empieza preguntando:

¿Qué estamos dispuestos a dejar que haga?

¿Qué ocurre cuando Casey no puede resolver la incidencia?

Debe existir un camino hacia una persona.

Salesforce plantea el escalado humano como parte de Casey y del Help Agent.

La parte importante no es simplemente transferir la conversación.

Es transferir contexto.

Porque el peor resultado posible es este:

Cliente:

Llevo diez minutos explicándole el problema al agente.

Agente:

Te paso con una persona.

Persona:

Hola. ¿Puedes explicarme qué te ocurre?

Eso no es automatización.

Es añadir un paso.

El handoff debería permitir que el equipo entienda:

• quién es el cliente

• qué estaba intentando hacer

• qué información ya proporcionó

• qué consultó Casey

• qué acciones se ejecutaron

• qué queda pendiente

Y ese contexto debe llegar de una forma útil para el agente humano, que muchas veces no está mirando la consola: si el equipo trabaja en Slack, el escalado tiene que llegar ahí con lo que hace falta para continuar.

Casey no elimina la necesidad de diseñar bien los casos

Case Management sigue importando.

Probablemente más.

Si Casey crea, actualiza o utiliza casos, la organización necesita tener claro:

• cuándo debe existir un caso

• qué estado representa cada momento

• qué prioridades existen

• qué campos importan

• quién debe ser el owner

• cuándo se escala

• cómo se relacionan casos similares

• qué información debe quedar registrada

Si cada equipo utiliza los estados de una forma diferente, la IA también trabajará sobre esa inconsistencia.

Un agente autónomo hace que el diseño del proceso sea menos visible para el cliente.

No lo hace menos importante.

¿Qué pasa con los SLA?

Un SLA no es simplemente un cronómetro.

Puede depender de:

• tipo de cliente

• contrato

• producto

• severidad

• canal

• horario

• país

• tipo de incidencia

• servicio contratado

Para que Casey pueda tomar una decisión útil alrededor de una incidencia, ese contexto tiene que estar disponible y ser interpretable.

Por ejemplo:

Este cliente tiene una incidencia crítica.

no es suficiente si el sistema no sabe qué significa «crítica» para ese contrato.

Y:

Esto hay que resolverlo hoy.

no es una regla si solo está en la cabeza del responsable del equipo.

Los agentes obligan a convertir conocimiento implícito en reglas, información o criterios utilizables.

¿Qué pasa si la información está fuera de Salesforce?

Aquí aparece uno de los problemas brownfield más importantes.

Customer Service rara vez vive únicamente en el CRM.

Para responder a una incidencia pueden hacer falta datos del:

• ERP

• sistema de pedidos

• eCommerce

• producto

• billing

• logística

• sistema técnico

• aplicación de mantenimiento

• plataforma de terceros

Salesforce puede tener al cliente.

Pero no necesariamente el dato que resuelve su problema.

En ese caso, la conversación sobre Casey pasa rápidamente a ser una conversación sobre integrar Salesforce con otros sistemas.

Un ejemplo industrial: la incidencia tiene que entender el producto

Imagina un fabricante.

Un distribuidor llama porque una máquina presenta una avería.

Para resolver correctamente la incidencia necesitas saber:

• qué máquina es

• qué configuración tiene

• dónde está instalada

• cuándo se entregó

• si está en garantía

• qué mantenimientos ha recibido

• qué incidencias anteriores tiene

• qué piezas están disponibles

• qué técnico puede atenderla

Responder:

Vamos a abrir una incidencia.

aporta poco.

El valor aparece cuando el proceso de Service tiene ese contexto.

Por eso, en Salesforce para fabricantes, el territorio de Customer Service está muy relacionado con:

• producto instalado

• garantías

• incidencias

• servicio técnico

• ERP

• activos

Casey puede convertirse en una nueva puerta de entrada al proceso.

El proceso sigue necesitando estar detrás.

Casey no arregla un Customer Service que ya tiene problemas

Hay una tentación bastante habitual con la IA:

utilizar una nueva interfaz para intentar evitar problemas antiguos.

No funciona así.

Si los casos están mal clasificados

Casey no crea automáticamente un modelo de casos coherente.

Si Knowledge está desactualizado

El agente puede tener acceso más rápido a información incorrecta.

Si los SLA no reflejan la realidad contractual

Automatizar decisiones sobre ellos puede hacer más visible el problema.

Si los agentes humanos consultan cuatro sistemas

Casey también necesitará ese contexto de alguna forma.

Si cada persona resuelve la misma incidencia de manera diferente

Primero hay que decidir cuál debería ser el proceso.

Si nadie sabe quién es propietario de Service Cloud

Añadir un agente introduce otra pieza que alguien tendrá que gobernar.

Por eso puede tener sentido auditar Salesforce antes de ampliar la autonomía.

¿Qué debería revisar antes de implantar Casey?

Empezaría por siete áreas.

1. Tipos de incidencia

No intentes automatizar todo Customer Service a la vez.

Busca situaciones:

• frecuentes

• suficientemente predecibles

• bien documentadas

• con reglas claras

• con riesgo controlable

Un buen primer caso podría ser:

Consultar el estado de un pedido.

Uno bastante peor podría ser:

Decidir una compensación excepcional para un cliente estratégico.

2. Knowledge

Pregunta:

• ¿Qué preguntas se repiten?

• ¿Existe una respuesta aprobada?

• ¿Está actualizada?

• ¿Quién mantiene el artículo?

• ¿Hay duplicados?

• ¿La respuesta depende de condiciones?

Un agente autónomo convierte Knowledge en infraestructura operativa.

Ya no es solo documentación.

3. Datos de cliente

Casey puede necesitar entender:

• cuenta

• contacto

• contrato

• producto

• historial

• pedidos

• incidencias anteriores

Decide qué contexto necesita para cada resolución.

No le des acceso a información porque sí.

4. Acciones

Lista las acciones que puede necesitar:

• consultar

• crear

• actualizar

• cancelar

• reprogramar

• escalar

Después clasifica:

autónoma / con confirmación / solo humana.

5. Excepciones

El proceso bonito suele ser fácil.

Las excepciones son donde empieza el proyecto real.

¿Qué ocurre si:

• no encuentra el pedido

• hay dos clientes con datos similares

• el producto está fuera de garantía

• la política no cubre ese país

• el SLA está a punto de incumplirse

• el cliente pide algo fuera de procedimiento?

Define qué debe hacer Casey cuando no sabe qué hacer.

6. Handoff humano

Decide:

• cuándo se escala

• a qué cola

• con qué prioridad

• con qué resumen

• qué acciones previas deben mostrarse

• qué contexto necesita el agente humano

No midas solo cuántos casos evita Casey.

Mide también qué calidad tienen los escalados.

7. Ownership

¿Quién es responsable de que Casey siga resolviendo bien dentro de seis meses?

Customer Service cambia.

Cambian:

• productos

• políticas

• contratos

• Knowledge

• equipos

• sistemas

• excepciones

Alguien debe mantener alineados:

proceso + Salesforce + Knowledge + agente.

Casey vs Service Assistant: ¿cuál es la diferencia?

No hacen el mismo trabajo.

Esta comparación es especialmente importante porque ambos viven en el territorio de Agentforce y Service.

Service Assistant vive sobre el registro del caso: resume lo ocurrido y propone al representante un plan de resolución paso a paso.

Casey atiende directamente al cliente.

Por tanto, una empresa podría utilizar ambos.

Casey para intentar resolver una incidencia antes de que llegue al equipo.

Service Assistant para ayudar al equipo cuando sí llega.

Casey vs Fin: ¿son lo mismo?

No.

Y esta comparación probablemente genere bastante confusión después de la adquisición de Fin por Salesforce.

Salesforce completó la adquisición de Fin el 10 de septiembre de 2026.

Fin es una plataforma de customer agent especializada en resolver consultas de cliente de principio a fin en todos los canales.

Salesforce explica que Fin amplía sus opciones de Customer Service junto con Agentforce.

A grandes rasgos:

No iría mucho más lejos todavía.

La adquisición se acaba de cerrar y el posicionamiento conjunto puede evolucionar.

La diferencia que sí podemos afirmar hoy es que Salesforce sigue presentando ambos como ofertas diferenciadas dentro de su cartera de Customer Service.

Si en los próximos meses converge naming, packaging o arquitectura, este artículo deberá actualizarse. Refleja la información disponible el 11 de septiembre de 2026.

¿Casey sustituye a los agentes de Customer Service?

No es la pregunta adecuada.

Hay trabajo donde un agente autónomo encaja muy bien:

• consultas repetitivas

• seguimiento

• comprobaciones

• procesos estandarizados

• cambios con reglas claras

• autoservicio

Y hay trabajo que puede seguir necesitando a una persona:

• excepciones

• clientes sensibles

• negociación

• situaciones ambiguas

• impacto económico elevado

• frustración

• decisiones fuera de política

El objetivo no debería ser:

¿Cómo eliminamos todos los casos humanos?

Sino:

¿Qué incidencias puede resolver Casey correctamente y cuáles merece la pena llevar antes a una persona?

¿Cómo medir si Casey funciona?

No utilizaría «número de conversaciones con IA» como KPI principal.

Puede haber muchas conversaciones y pocas resoluciones.

Miraría métricas vinculadas al proceso.

Por ejemplo:

• porcentaje de solicitudes resueltas sin escalado

• reincidencia

• escalados posteriores

• tiempo hasta resolución

• reaperturas

• casos mal clasificados

• calidad del handoff

• satisfacción

• tipos de incidencia que Casey no puede completar

Pero no existe una cifra universal que diga si Agentforce está funcionando.

La métrica debe partir de la incidencia que quieres resolver.

¿Por dónde empezaría en una empresa que ya utiliza Salesforce?

Por un problema concreto.

No por Casey.

Por ejemplo:

Tenemos muchas consultas sobre estado de pedidos y el equipo pierde tiempo consultando el ERP.

Eso obliga a responder:

1. 01

   ¿Dónde está el pedido?

2. 02

   ¿Puede Salesforce acceder al estado?

3. 03

   ¿Cómo identificamos al cliente?

4. 04

   ¿Qué puede mostrarle?

5. 05

   ¿Hay información sensible?

6. 06

   ¿Qué ocurre si existe una incidencia?

7. 07

   ¿Cuándo escala?

Entonces sí tiene sentido hablar de Casey.

Lo mismo con:

• cambios de cita

• consultas de garantía

• estado de una incidencia

• actualización de datos

• preguntas sobre un servicio

Elegir primero el agente y después buscarle trabajo suele ser el orden equivocado.

¿Qué cambia realmente con Casey?

Que Salesforce está acercando Agentforce a un problema bastante fácil de reconocer:

Customer Service tiene demasiadas interacciones que empiezan siempre desde cero.

El cliente pregunta.

El agente busca quién es.

Consulta qué ha ocurrido.

Busca documentación.

Comprueba sistemas.

Ejecuta una acción.

Registra el resultado.

Casey intenta automatizar una parte mayor de esa cadena.

Eso puede ser muy útil.

Pero también expone rápidamente todo lo que en el proceso actual no está preparado:

• datos incompletos

• Knowledge débil

• integraciones

• excepciones no documentadas

• permisos

• reglas

• handoffs

¿Dónde tendría sentido empezar?

Elige una incidencia frecuente y relativamente controlable.

Describe cómo se resuelve hoy.

Identifica:

• información necesaria

• sistemas consultados

• decisiones

• acciones

• excepciones

• escalado

Después pregunta qué parte puede asumir Casey.

Si para responder necesitas rediseñar el proceso, evolucionar Salesforce probablemente forma parte del proyecto.

Si no sabes qué está bien o mal configurado, empieza por una auditoría de Salesforce.

Y si la resolución depende del ERP u otras herramientas, la integración de Salesforce con otros sistemas no es una cuestión secundaria.

Es parte del caso de uso.