Cómo derivar consultas de WhatsApp a una persona con contexto

La derivación termina cuando alguien toma el caso

Un asistente recibe una consulta por WhatsApp, identifica que requiere una decisión comercial y avisa al equipo. Ese aviso todavía no significa que una persona haya tomado la conversación. Entre el mensaje automático y la respuesta humana puede quedar una consulta sin responsable, aunque todos los nodos del flujo hayan terminado correctamente.

El diseño debe distinguir tres eventos: solicitar la derivación, asignar un responsable y confirmar que ese responsable aceptó el caso. Esta guía usa un escenario de referencia; no describe resultados de un cliente. El objetivo es poder seguir cada consulta desde la entrada hasta una respuesta verificable.

Definir cuándo debe intervenir el equipo

No todas las consultas necesitan la misma salida. Una petición de hablar con alguien debe tener una ruta directa. También conviene derivar una excepción comercial, una respuesta que necesita información faltante o un caso que el asistente no puede resolver con las fuentes disponibles. Los motivos deben ser categorías que el equipo pueda revisar.

La ruta depende de la intención y de la responsabilidad, además del texto recibido. Por ejemplo, una modificación de presupuesto puede ir al área comercial y una incidencia de servicio al equipo operativo. Si no hay información suficiente para decidir, el caso debe quedar en una cola de revisión, con una persona responsable de esa cola.

• Definir motivos de derivación y equipo destino.
• Permitir que la persona solicite atención humana.
• Separar la cola de revisión de los casos ya asignados.

Entregar una ficha que permita continuar

La ficha de derivación debe reunir el identificador del contacto, el ID de la oportunidad o solicitud, el motivo, un resumen de lo conversado y el próximo paso pendiente. El resumen debe distinguir hechos confirmados de interpretaciones del asistente. Si falta un dato, debe decir que falta; no completar el contexto con una suposición.

Ejemplo: consulta por instalación, zona informada, disponibilidad solicitada y presupuesto pendiente de revisión. La persona que recibe el caso debería encontrar un enlace al registro y al historial autorizado. Copiar toda la conversación a un aviso puede exponer información innecesaria y dificultar la lectura; el acceso al detalle se resuelve desde el sistema correspondiente.

Usar estados y tiempos de atención explícitos

Un esquema inicial puede ser recibido, derivación solicitada, asignado, tomado, respondido y cerrado. Cada cambio tiene un responsable y una fecha. El CRM o registro operativo conserva ese estado; una notificación en otro canal comunica el cambio, pero no lo reemplaza. Así se puede distinguir una consulta pendiente de una que ya está siendo atendida.

El equipo debe definir sus horarios y el tiempo esperado para tomar un caso. Fuera de horario, el mensaje informa cuándo se retomará la atención sin prometer disponibilidad inexistente. Si nadie acepta el caso dentro del plazo definido, una regla lo escala al responsable de la cola. Los plazos se acuerdan con la operación; no se eligen solo porque sean fáciles de configurar.

Evitar respuestas simultáneas y avisos repetidos

Cuando una persona toma la conversación, el asistente necesita conocer esa transición. Definí qué automatizaciones pueden continuar y cuáles deben esperar: por ejemplo, registrar nuevos mensajes puede seguir siendo útil mientras se suspenden respuestas automáticas sobre la negociación. La devolución al asistente también debe tener una condición explícita.

Una derivación necesita una clave estable por caso. Un mensaje repetido o un reintento no debería generar dos asignaciones activas para la misma solicitud. Antes de enviar un segundo aviso, el flujo comprueba el estado y el responsable. Si la respuesta del sistema es ambigua, registra la duda y consulta el resultado anterior antes de volver a asignar.

Probar y medir la atención que quedó pendiente

Antes de activar el flujo, probá un pedido de atención humana, un caso fuera de horario, un responsable ausente, dos mensajes del mismo contacto y una consulta con contexto incompleto. Cada prueba debe dejar una salida visible. También comprobá qué ocurre cuando el CRM no confirma el cambio de estado.

Para evaluar el proceso, medí cuánto tarda un caso en pasar de solicitado a tomado, cuántos se reasignan y cuántos llegan al cierre sin el dato necesario. Estas señales ayudan a encontrar problemas de coordinación. Si necesitás integrar el canal con el CRM, el primer entregable debería ser este mapa de estados y responsabilidades, seguido por la automatización.