Soluciones · Transporte y logística
La despachación por voz, construida como mecanismo, no como promesa: una tabla con estados explícitos, tres intentos con dos minutos de distancia, el resultado de la llamada escrito de forma estructurada y un filtro que saca el número del conductor de todo lo que llega al modelo, para que no pueda dictarse al cliente.
Ya construidoEl mecanismo de despacho está escrito y migrado en nuestra plataforma vocal: la tabla `courier_calls` con siete estados posibles, tres intentos implícitos, pausa de 120.000 ms entre ellos y el resultado de la llamada guardado de forma estructurada, además de cinco funciones de servidor que lo usan — inicio de la llamada al courier, verificación del resultado, barrido de las llamadas que quedaron colgadas, identificación de quien llama de vuelta y el webhook posterior a la llamada. La segunda implementación es el filtro de salida escrito para un cliente de transporte, que elimina recursivamente los campos de contacto del conductor del resultado de la herramienta, manteniendo los números del despacho. La reserva, dicha antes de que preguntes: la parte de teléfono pasa por un host SIP, y el host por el que van nuestras líneas de prueba no responde a la fecha de escritura — no te damos un número de demostración que no pudiéramos levantar delante de ti.
En una empresa de transporte o de entrega, la mayoría de las llamadas recibidas son la misma pregunta hecha por personas distintas: dónde está la mercancía, a qué hora llega, por qué no ha llegado. La respuesta no está en un documento y no está en un sistema — está en la cabeza del conductor, que conduce. El despacho hace la conexión: toma la llamada del cliente, llama al conductor, vuelve al cliente. Ese trabajo ocupa a una persona entera y se hace cien veces al día, con las mismas tres frases.
Hemos construido exactamente esta cadena, como mecanismo con estados, no como función de marketing. Un agente habla con el cliente. Cuando necesita una respuesta que no tiene, llama a una función que inicia una segunda llamada — hacia el courier — vinculada a la conversación de la que salió. Esa llamada tiene su propia fila en una tabla, con estado que pasa por `calling`, `in_progress`, `retrying`, `completed`, `failed`, `no_answer`, `timeout`, con el número del intento, con un máximo de tres intentos y una pausa de dos minutos entre ellos. El resultado se escribe de forma estructurada: el resumen de lo que dijo el courier, el tiempo estimado, la posición.
La parte que se pasa por alto fácilmente y que nosotros tratamos como un requisito, no como una precaución: el número de teléfono del conductor no tiene derecho a llegar al cliente. No es una instrucción escrita en el prompt del agente, porque una instrucción en un prompt puede eludirse. Es un filtro que recorre recursivamente el resultado de la herramienta y elimina los campos de contacto del conductor antes de que ese resultado llegue al modelo — manteniendo los números del despacho. Lo que fue eliminado no puede dictarse, sin importar cómo pregunte el agente.
Y el límite más importante es uno de infraestructura, no de inteligencia: un agente de voz por teléfono depende de un host SIP entre tu operador y la plataforma. Cuando ese host cae, las llamadas no salen, y la firma del fallo es reconocible — solicitud caducada, identificador de llamada vacío, duración cero. El host por el que pasan nuestras líneas de prueba no responde a la fecha de escritura de esta página. En la web, el recorrido de voz es verificable hoy; por teléfono, la primera etapa de cualquier trabajo es establecer en qué host entran tus números.
Qué incluye
Cuando la respuesta no está en la información que tiene, el agente llama a una función de servidor que llama al courier. La llamada al courier mantiene su vínculo con la conversación de la que partió, mediante un identificador de la conversación padre — así siempre se sabe para quién se llamó y por qué. El contexto del pedido se transmite como estructura, desde tu sistema de pedidos, no se dicta.
Siete estados escritos como restricción en la base de datos: `calling`, `in_progress`, `retrying`, `completed`, `failed`, `no_answer`, `timeout`. Más el número del intento actual. La diferencia entre «no respondió» y «se cayó el sistema» es visible en los datos, no adivinada por los registros — y eso importa cuando alguien pregunta mañana por qué el cliente no recibió una respuesta.
Por defecto: tres intentos, con 120.000 milisegundos — dos minutos — entre ellos, ambos escritos como valores por defecto en la tabla y en la configuración del proceso. Un conductor que circula por una carretera sin señal no responde al primer intento. Un sistema que llama una sola vez y declara fracaso es inútil exactamente en el caso para el que fue construido.
Lo que dijo el courier se escribe como resumen, tiempo estimado y posición, en un campo estructurado vinculado a la fila de la llamada. Desde ahí puede seguir más lejos: hacia el agente que habla con el cliente, hacia la central, hacia tu sistema. Un webhook después de la llamada y una función de barrido para las llamadas que quedan enganchadas completan la cadena, para que una llamada perdida no se quede en el estado `calling` indefinidamente.
El filtro de salida recorre recursivamente el resultado de la herramienta y elimina los campos de contacto del conductor, manteniendo los números de la central. Está escrito en código, aplicado puntualmente en la integración donde aparece el problema. El motivo es simple: la interfaz del proveedor devolvía los números de los conductores en la respuesta, y la política de la empresa prohibía que el agente se los diera a los clientes. Una instrucción en el prompt se habría esquivado con una pregunta bien formulada; un campo eliminado no se puede esquivar.
El courier que devuelve una llamada es identificado por una función dedicada, así que no entra en el flujo general de clientes y no se le lee el menú desde el principio. Parece un detalle; es la diferencia entre un sistema que los conductores usan y uno que esquivan llamando directamente a la central, lo que anula todo el trabajo.
Transferencia ciega por `##` y transferencia asistida por `*2`, con contexto de aterrizaje en el plan de llamada que distingue las extensiones internas de cuatro cifras de los números externos. Cuando el cliente pide insistentemente a una persona — y en transporte la pide, porque su carga se retrasa — la transferencia no debe pasar por un menú.
En el recorrido de OpenAI Realtime: detección semántica del habla con umbral 0,5, amortiguación de 300 ms, 500 ms de silencio, interrupción permitida por defecto. En el recorrido de ElevenLabs, el evento de interrupción se transmite a la central para cortar la reproducción. `turn_timeout` se establece por agente. En una llamada de transporte, donde el interlocutor suele estar en una cabina ruidosa, esos umbrales son la mitad de la calidad percibida.
No decide la ruta ni reoptimiza las entregas. No da una tarifa si no está conectado a la fuente que la calcula. No sabe dónde está la carga si nadie se lo ha dicho — ni el courier ni tu sistema. Y no sustituye al despachador: le quita las llamadas repetitivas y le deja las excepciones, que son exactamente la parte por la que se le paga.
Traseul
La primera etapa no es el guion del agente, sino la telefonía: por qué trunk entra el número, quién lo controla, qué ocurre cuando el host no responde. Entregamos una verificación escrita de la ruta y, si la ruta no es segura, lo decimos antes de construir algo encima de ella. Un agente excelente en un host que se cae es un agente que no responde.
Qué le pregunta el agente al courier, en qué orden, qué hace cuando el courier no responde al tercer intento, qué pasa cuando la respuesta es poco clara, cuándo transfiere al despachador humano. Entregamos el escenario escrito y la lista de estados a los que puede llegar una llamada —incluidos los feos.
El contexto del pedido viene de tu sistema, y antes de que el resultado de una herramienta llegue al modelo pasamos por la lista de campos que no pueden salir. Entregamos la integración, la lista escrita de los campos filtrados y la prueba de que el filtro se aplica al resultado, no a las instrucciones.
Arrancamos sobre una parte de las llamadas, con la transferencia al despachador configurada de forma amplia, y leemos los transcriptos. A partir de ahí se ajustan los umbrales de interrupción, `turn_timeout`, la formulación de las preguntas y el umbral a partir del cual el agente se rinde. Entregamos el informe de estas llamadas, con las decisiones de ajuste, no solo el agente arrancado.
Los datos
Las reglas difieren de una industria a otra. Estas son las que se aplican en transporte & logística.
Un caso
La situación
En un flujo de entrega, la pregunta «dónde está mi pedido» no tiene respuesta en ningún sistema: la respuesta está en el courier. La variante simple —el agente le escribe un mensaje al courier y espera— falla con el primer courier que conduce y no mira el teléfono.
Qué construimos
Hemos construido la dispatching como tabla, no como función. Cada llamada al courier tiene una fila con siete estados posibles, el número del intento, máximo tres intentos, una pausa de dos minutos entre ellos y el resultado guardado de forma estructurada — resumen, tiempo estimado, posición. La fila mantiene el vínculo con la conversación del cliente de la que salió. Alrededor de la tabla: la función que inicia la llamada, la que verifica el resultado, la escoba para las llamadas que quedaron colgadas, la identificación del courier que devuelve la llamada y el webhook después de la llamada.
Qué salió
Se puede responder, en cualquier momento y a partir de datos, a las preguntas que recibe a diario un centro de despacho: si se llamó, cuántas veces, qué respondió, por qué no se llamó. Una llamada perdida ya no queda bloqueada en un estado intermedio, porque hay quién la barra.
Qué no dice el caso
El mecanismo está escrito y migrado en la plataforma; la parte de telefonía depende de un host SIP, y la por la que pasan nuestras líneas de prueba no responde en la fecha de escritura. No presentamos la dispatching como algo que puedas probar llamando hoy a un número nuestro.
Preguntas
Llama. Existe una función de servidor que inicia la llamada al courier, vinculada a la conversación de la que salió, con el contexto del pedido transmitido como estructura. La llamada tiene su propia fila en una tabla, con estado, número de intento y resultado — así que se puede responder en cualquier momento a la pregunta «se llamó, y qué dijo».
Se reintenta. Por defecto tres veces, con dos minutos de diferencia, valores escritos en la tabla y en la configuración del proceso. Si ni a la tercera responde, la llamada queda en el estado `no_answer` — un estado distinto de `failed`, que significa que algo falló de nuestro lado. Esa distinción es la razón por la que vale la pena una tabla, no un registro.
No, y no porque le hayamos dicho que no lo haga. Los campos de contacto del conductor se eliminan recursivamente del resultado de la herramienta antes de que ese resultado llegue al modelo. Los números del centro de despacho permanecen. Lo que no llega al modelo no se puede dictar, por muy hábilmente formulada que esté la pregunta.
Puede decir lo que le dijo el courier en la última llamada, con la hora de esa llamada, o lo que lee en tu sistema si está conectado a él. Lo que no hace — y es una decisión, no una limitación — es estimar por su cuenta. Una estimación inventada por un agente se convierte en una promesa que soporta el conductor en la puerta.
No hoy. La parte de telefonía pasa por un host SIP, y el host por el que van nuestras líneas de prueba no responde en la fecha de escritura de esta página. No ponemos en el sitio un número que no podríamos levantar ante ti. El recorrido vocal en la web es otra historia: ahí se puede verificar de inmediato.
La configuración del agente admite 32 idiomas, y el rumano es el idioma predeterminado de un agente nuevo. El idioma se establece por agente, así que el agente que habla con el cliente y el que llama al courier pueden configurarse de forma diferente. Lo que hay que saber: para la síntesis de voz en idiomas distintos del inglés, el modelo predeterminado es el rápido, y la variante de mejor calidad es visiblemente más lenta — el compromiso se elige conscientemente.
Se detiene. La detección semántica del habla tiene umbral 0,5, colchón de 300 ms y 500 ms de silencio, y la interrupción está permitida por defecto; en el otro recorrido, el evento de interrupción se transmite a la central para cortar la reproducción. Si un agente no puede ser interrumpido, no es un problema de tono, sino de configuración — y de respuestas demasiado largas.
Tú decides cuánto, porque tú eres el operador de datos. Lo que debes saber sobre el estado actual de la plataforma: la eliminación a petición está implementada como función, y la eliminación automática al vencimiento, configurable por espacio de trabajo, no lo está — se hace mediante procedimiento. Preferimos que lo sepas de nosotros, no a partir de una auditoría.
No. Le quita la parte repetitiva — la misma pregunta, la misma llamada, la misma respuesta — y le deja las excepciones. La transferencia hacia él sigue estando a un código en el teclado, y en transporte las excepciones son frecuentes: mercancía rechazada, dirección equivocada, cliente que no responde. Ahí hace falta una persona, y mejor que sea una persona que no haya respondido antes a cien «¿dónde está el paquete?».
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.