Un cliente pide hablar con una persona. El bot dice que alguien se va a unir al chat, pero no llega nadie. Para corregir esa experiencia, primero hay que decidir adónde va la solicitud y quién la responderá.
Esta guía distingue una transferencia en directo de un ticket de soporte. Usa el comportamiento actual de escalación de Agentkit para explicar los límites de la configuración. Después propone una política y comprobaciones de aceptación que puedes adaptar a tu equipo de soporte. Los detalles del producto se verificaron el 6 de octubre de 2026. Los ejemplos son ilustrativos y no son resultados de clientes.
¿Cómo debo diseñar los activadores de transferencia del bot a una persona para soporte?
Define activadores para las solicitudes explícitas de atención humana, las respuestas repetidas que no ayudan y las tareas fuera del alcance del bot, y prueba cada uno antes del lanzamiento. Agentkit puede crear un registro de soporte mediante seis sistemas externos de helpdesk o CRM conectados, pero su acción genérica Escalate to Human no conecta a una persona en directo al chat.
Elige un destino, recoge los datos de contacto que necesita y explica al cliente qué ocurrirá después. La creación correcta de un ticket confirma que se registró la solicitud. No confirma que una persona la haya leído ni que vaya a responder dentro de un plazo concreto.
Elige la transferencia que tu equipo puede ofrecer
Una transferencia en directo necesita un canal atendido y una integración que permita a una persona continuar la conversación. Una transferencia mediante ticket registra la solicitud para su seguimiento posterior. El cliente debe saber cuál recibirá.
La acción genérica Escalate to Human de Agentkit admite Zendesk, Freshdesk, Help Scout, Intercom, HubSpot y Salesforce. El destino recibe un ticket, un caso o una conversación según el proveedor. Salesforce Live Chat es una acción independiente. Elegir Salesforce como destino de la escalación genérica crea un caso, no una sesión de chat en directo.
Agentkit Help Desk es otro destino, nativo. Requiere una conversación guardada, un plan con acceso a Help Desk y Help Desk habilitado para ese agente. También necesita una dirección de correo válida del solicitante. Los tickets del chat del sitio no tienen un editor de respuestas en la bandeja de Help Desk y no añaden al widget un canal de respuesta humana en directo. Tu equipo necesita otra vía de seguimiento, como su propio correo de soporte, antes de activar el flujo.
Para un destino externo, conecta el proveedor y confirma que tu plan admite la acción. Después añade y habilita la acción para el agente. Verifica sus permisos y la bandeja de entrada del equipo receptor con una solicitud de prueba inocua.
Define los activadores según las decisiones de soporte
Empieza con decisiones que tu equipo pueda explicar. No trates cada mención de "humano" o cada frase negativa como la misma solicitud.
| Activador | Ejemplo | Política que debes probar |
|---|---|---|
| Solicitud explícita | "Por favor, déjame hablar con una persona." | Ofrece la vía de soporte admitida y recoge los datos de contacto necesarios. |
| Fallo repetido | "Esa respuesta sigue sin resolver mi problema." | Deja de repetir el mismo consejo y ofrece una escalación. |
| Fuera de la autoridad del bot | Un cargo impugnado o una solicitud para cambiar el acceso a la cuenta | Deriva al equipo responsable en vez de inventar una decisión o confirmar un cambio no autorizado. |
| Urgencia o frustración | "Mi cuenta está bloqueada y no puedo trabajar." | Ofrece ayuda pronto y describe el canal real de seguimiento. No prometas una respuesta de emergencia sin personal disponible. |
| Regla de cliente verificada | Una cuenta conocida cumple los requisitos para otra vía de soporte | Usa datos de cliente fiables y una ruta configurada. Que un visitante se declare VIP no verifica su identidad. |
Estas son políticas recomendadas, no interruptores integrados de activadores deterministas. La acción de Agentkit tiene instrucciones When to use que orientan al modelo. Debes probar las instrucciones en lenguaje natural con distintas formulaciones y en los idiomas admitidos. Por sí solas no establecen una puntuación fiable del sentimiento, una consulta de estado VIP ni un contador fijo de respuestas rechazadas.
La documentación de escalación de Intercom distingue las instrucciones en lenguaje natural, las reglas basadas en datos y el enrutamiento posterior a la escalación. Son distinciones útiles para evaluar un flujo, pero no implican que Agentkit implemente el sistema de reglas de Intercom.
Proporciona contexto útil a la persona
Para un proveedor externo conectado, la escalación de Agentkit recoge un asunto, un resumen del problema, un correo válido y un nombre cuando está disponible. El contexto del ticket incluye hasta los 50 mensajes guardados más recientes que no son mensajes de herramientas. Cada mensaje mostrado se limita a 2.000 caracteres. La solicitud actual se incluye cuando está disponible.
Es un contexto limitado, no una promesa de transcripción completa. El resumen se limita a 2.000 caracteres y el asunto a 150 caracteres. La transcripción mostrada contiene el texto de los mensajes, no los archivos adjuntos. El proveedor receptor puede imponer otros límites. En un chat largo, quizá haya que repetir en el resumen un número de pedido mencionado al principio. Verifica qué muestra realmente el destino elegido. El ticket nativo de Help Desk enlaza con su conversación guardada. No supongas que su vista es idéntica al cuerpo del ticket de un proveedor externo.
Pide solo lo que necesita el equipo. Una dirección de correo escrita sirve para el seguimiento, pero no demuestra que el cliente sea propietario de una cuenta. No pidas a los visitantes que peguen contraseñas, datos de tarjetas de pago o credenciales privadas en el chat.
Un resumen útil indica qué necesita el cliente, qué ha intentado ya el bot y qué sigue sin resolverse. Si tu equipo necesita un motivo de escalación etiquetado o una cola concreta, configura y verifica ese flujo. No supongas que la acción genérica lo proporciona automáticamente.
Fija expectativas sin inventar disponibilidad
En un flujo mediante ticket, explica al cliente que soporte hará el seguimiento por el canal acordado. Incluye un compromiso de tiempo de respuesta solo cuando el equipo receptor sea responsable de él y pueda cumplirlo. No digas "un agente se está uniendo" solo porque se creó un ticket.
Para solicitudes fuera del horario de atención, recoge el correo requerido y el resumen del problema, y después comunica el resultado real de la creación. Si la conexión ha caducado o falla la creación del ticket, ofrece al cliente una vía de contacto alternativa que funcione. Un mensaje tranquilizador no sustituye a un registro de soporte que falta.
El anuncio de la integración de Chatbase con Zendesk expresa la misma distinción entre canales. Su flujo de tickets usa seguimiento por correo. Su integración con Sunshine es una vía independiente de chat en tiempo real. Comprueba la integración real antes de prometer una transferencia en directo.
Una instrucción ilustrativa para adaptar
La siguiente plantilla en inglés es una política inicial para un flujo mediante ticket. No es un clasificador probado ni una regla de enrutamiento ejecutable.
Use the support-ticket action when the visitor clearly asks for a person, says the suggested answer did not help, or needs a decision outside your authority. Before calling it, collect or confirm a valid follow-up email and summarize the unresolved issue. Do not ask for passwords or payment-card details. After a successful result, explain that the request was recorded for follow-up. Do not claim a human has joined or promise a reply time unless the business has supplied a supported commitment. If creation fails, explain the problem and provide the business's alternative support contact. Do not say a ticket was created when the action failed.
Añade las instrucciones de activación al campo When to use de la acción y mantén las expectativas del cliente coherentes con las instrucciones de tu agente. Prueba el flujo completo, incluida la bandeja de entrada receptora, en vez de revisar solo las palabras del bot.
Comprueba el flujo antes del lanzamiento
Usa solicitudes ficticias y una dirección de soporte que controles. Los siguientes casos son una hoja de aceptación, no resultados de pruebas ya realizadas.
| Caso de prueba | Qué verificar |
|---|---|
| Solicitud clara de una persona | La acción habilitada correcta se ofrece o invoca después de recoger los datos necesarios. |
| Dos respuestas sin éxito | El bot ofrece una escalación en vez de repetir el mismo consejo. Este umbral es tu política de prueba, no un contador integrado. |
| No hay un correo conocido en la conversación o el registro del contacto | El bot pide un correo válido antes de intentar la creación. |
| Conversación larga | El registro receptor contiene contexto reciente útil. Los detalles anteriores importantes se conservan en el resumen. |
| Proveedor desconectado | El bot comunica el fallo y ofrece la vía de soporte alternativa configurada. |
| Help Desk deshabilitado | No se afirma que se haya creado correctamente un ticket nativo. |
| Solicitud fuera del horario | El bot describe correctamente el seguimiento sin inventar una cola en directo ni un plazo de respuesta. |
| Solicitud de escalación repetida | Comprueba si se reutiliza el registro existente y si el cliente recibe un estado preciso. |
Anota el identificador del registro receptor y verifica que un equipo identificado puede encontrarlo. Repite los casos de activación en cada idioma que ofreces. Un mensaje que parece correcto en el chat es solo una parte de la aceptación.
Mide la creación y la respuesta por separado
Registra los intentos de escalación, la creación correcta de registros, los fallos de entrega y el tiempo hasta la primera respuesta humana. Usa las marcas de tiempo del helpdesk receptor o tu propia instrumentación para medir el tiempo de respuesta. Los registros de conversación de Agentkit por sí solos no constituyen un panel completo de tiempos de transferencia ni de satisfacción posterior.
Revisa una muestra de casos escalados para detectar contexto ausente y preguntas repetidas. Si encuestas la satisfacción, guarda el número de respuestas y el canal junto a la puntuación. La guía de KPI de chatbots explica por qué la atención sin escalación y la resolución necesitan definiciones distintas.
Empieza con un destino admitido y un equipo responsable del seguimiento. Configura la acción de escalación, ejecuta los casos de aceptación y confirma la recepción antes de invitar a los clientes a usarla.
Lecturas relacionadas:
