Diseña una derivación humana que resulte útil

Decide cuándo hace falta una persona

Enumera las situaciones que deben salir de la función del bot. Pueden incluir reclamaciones sin resolver, solicitudes sobre una cuenta concreta, información de producto ausente o excepciones que exigen aprobación. Explica con lenguaje sencillo el motivo de cada límite. El visitante debe entender por qué necesita otro paso sin recibir una larga explicación de tecnología interna. Derivar forma parte del diseño del servicio; no significa que el visitante haya preguntado algo incorrecto.

Elige un destino real para cada tipo de solicitud. Puede ser un formulario atendido, un canal de soporte existente o instrucciones para contactar con el equipo adecuado. Confirma quién se responsabiliza de ese destino y qué información necesita. Si todavía no existe una vía, deja la carencia visible en la lista de lanzamiento. No escribas que un compañero responderá automáticamente si nadie ha aceptado recibir y gestionar la solicitud.

Pide el contexto mínimo útil

En una consulta, identifica qué necesita el destinatario para entender la pregunta y responder. Una descripción breve y un canal de contacto pueden bastar; demasiados campos pueden pedir información sin propósito claro. Explica en el recorrido para qué se solicita cada dato. Usa información ficticia al probar y evita invitar a pegar registros sensibles en un chat o formulario sin verificar.

Distingue preparar una consulta de enviarla. Si solo se muestra un resumen para copiar, indícalo. Si el formulario envía un mensaje, confirma que la entrega se ha probado y que el estado de éxito refleja lo que sabe el sistema. Una pantalla que diga recibido no debe basarse únicamente en pulsar un botón. El texto debe corresponder a la acción real, incluida la incertidumbre o el paso que todavía deba completar el visitante.

Cierra el recorrido con un proceso responsable

Acuerda cómo reconocerá, revisará y responderá el equipo estas solicitudes. Usa un plazo de respuesta solo si el equipo lo ha aprobado y puede cumplirlo. Decide cómo puede insistir un visitante si no recibe noticias y haz visible esa vía. La derivación no debería prometer una resolución, sino explicar con exactitud la siguiente etapa y proporcionar una referencia utilizable cuando exista realmente.

Prueba el recorrido completo con una consulta claramente identificada como prueba: experiencia del visitante, recepción del equipo y vía de respuesta. Comprueba el mismo recorrido en todos los idiomas admitidos. Registra los pasos manuales para no confundirlos con integraciones automáticas. Después de publicar, utiliza los problemas observados para mejorar información y recorrido. Una pregunta confusa repetida puede necesitar otra respuesta; un fallo de entrega necesita una corrección operativa, no un texto más tranquilizador.

Escribe el mensaje de derivación antes de añadir un formulario. Si no puedes explicar quién recibe la solicitud, qué sucede después y qué debe hacer aún el visitante, el proceso no está suficientemente claro. Resuelve esas decisiones antes de pulir la presentación visual del recorrido.

Patrocinado