Artículo
Agentes personales: contactos y clientes
En una perspectiva del 19 de octubre de 2026, Kishan Chetan, responsable de Agentforce y Service Cloud en Salesforce, pronostica que los agentes personales podrían aumentar los contactos con atención al cliente. Su argumento incluye consultas repetidas y gestiones ante varias empresas. La pieza no aporta datos, muestra, período de observación ni modelo de pronóstico.
Este análisis propone una forma de examinar esa posibilidad: separar cuántas veces alguien contacta, qué necesita y qué resultado obtiene. Un registro de actividad puede crecer sin que aumente el número de clientes o se complete más trabajo.
Un contacto no es una solicitud
Un contacto es una interacción registrada en un canal: un formulario recibido, una llamada o un mensaje de chat. Una solicitud es la necesidad que se intenta atender. Un resultado es el cambio comprobado que permite cerrar esa necesidad según un criterio acordado. Son unidades diferentes y conviene nombrarlas antes de calcular indicadores.
La distinción evita interpretar una transferencia entre canales como una nueva demanda. También evita el error contrario: agrupar necesidades diferentes porque pertenecen a la misma persona. Un cliente puede pedir una reparación y, después, solicitar información sobre otro servicio; conservar su identidad no convierte ambas gestiones en una sola.
Un caso multicanal que sigue pendiente
El siguiente caso es ficticio y se plantea sobre papel, sin conversaciones reales ni resultados de un producto. Una persona consulta a un taller de bicicletas por el estado de una reparación. Primero envía un formulario; después, un asistente que se presenta como su agente llama para preguntar por el mismo trabajo. Finalmente, la persona abre un chat porque aún necesita una fecha confirmada.
El registro del ejercicio contiene tres contactos. Para tratarlos como una única solicitud, la persona revisora comprueba una referencia común de reparación y confirma que las tres interacciones buscan la misma respuesta. El nombre parecido o la cercanía entre horarios no bastan para unir registros.
La solicitud permanece pendiente: recibir el formulario, contestar la llamada o abrir el chat no acredita que se haya confirmado la fecha. Ese estado debe seguir visible aunque cada canal tenga una interacción atendida. Así se conserva la diferencia entre haber respondido y haber resuelto.
Registrar la procedencia sin adivinarla
Para este ejercicio, la procedencia del contacto puede registrarse como persona declarada, agente declarado o desconocida. La etiqueta describe lo que se conoce por una manifestación explícita; no certifica por sí sola quién representa a quién ni con qué alcance.
Una llamada que se presenta como realizada por un asistente permite anotar esa declaración. No autoriza a completar los campos que faltan. Si el origen no está declarado, queda desconocido: la redacción, la velocidad de respuesta o el dispositivo utilizado no sustituyen la evidencia de procedencia.
También conviene separar esa etiqueta de la referencia que vincula la solicitud. En el caso del taller, reconocer el trabajo consultado no demuestra automáticamente que quien llama pueda modificar sus condiciones. La relación entre contactos ayuda a entender el recorrido; cualquier acción solicitada requiere su propia comprobación.
Una matriz para conservar las diferencias
Desliza la tabla si no ves ambas columnas.
| Registro | Qué conserva |
|---|---|
| Contacto | Canal y momento de la interacción. |
| Solicitud | Necesidad y referencia confirmadas. |
| Procedencia | Declaración disponible o desconocida. |
| Resultado | Prueba del cierre o estado pendiente. |
| Vínculo | Motivo para unir o separar contactos. |
La matriz no prescribe una aplicación ni reproduce una función del proveedor. Sirve para revisar qué se está contando. Si el equipo cambia una regla de agrupación, debería conservar la versión utilizada; de otro modo, un descenso de solicitudes podría reflejar una clasificación distinta.
Elegir denominadores que respondan una pregunta
Para estudiar repetición, el denominador puede ser el conjunto de solicitudes observadas y el numerador las que recibieron otro contacto dentro de una ventana definida. Para estudiar cierre, se necesita una base de solicitudes comparables y evidencia del resultado. Mezclar contactos en el numerador con clientes en el denominador produce otra medida, que debe explicarse como tal.
La ventana importa. Una solicitud iniciada al final del período puede seguir pendiente porque todavía no ha tenido tiempo de completarse. Compararla con otra observada durante todo el recorrido sin distinguir esa diferencia debilita la interpretación. Es preferible informar qué casos continúan abiertos y cuándo se volverán a revisar.
Para evaluar un escenario de mayor tráfico, habría que observar si cambian las solicitudes únicas, los contactos por solicitud y el trabajo necesario para resolverlas. Una variación aislada no explica su causa: también podrían cambiar los canales disponibles, las reglas de registro o los plazos del servicio.
La lectura sobre confianza y demostraciones en Intercom aporta contexto para separar opiniones de resultados. El análisis de Klaviyo y las preguntas sobre datos complementa la definición de métricas y períodos.
Preguntas frecuentes
¿Más contactos significan más clientes?
El conteo de contactos no permite deducirlo: primero hay que establecer cuántas personas y solicitudes distintas representa.
¿Cuándo unir dos interacciones?
Cuando exista evidencia de que corresponden a la misma necesidad y referencia, conservando el motivo de la unión.
¿Cómo contar una solicitud sin cierre?
Debe permanecer pendiente dentro de la ventana declarada, sin convertir una respuesta enviada en un resultado confirmado.
¿Qué hacer si no se sabe quién contactó?
Registrar procedencia desconocida y mantener esa incertidumbre en el análisis, sin asignar una identidad por el estilo del mensaje.
Para contrastar tus criterios de evaluación, participa en la Comunidad IA.
