Soluções · Transporte e logística
A despacha por voz, construída como mecanismo, não como promessa: uma tabela com estados explícitos, três tentativas com dois minutos de intervalo, o resultado da chamada escrito de forma estruturada e um filtro que retira o número do motorista de tudo o que chega ao modelo, para que não possa ser ditado ao cliente.
Já construídoMecanismul de dispecerizare e scris și migrat în platforma noastră vocală: tabela `courier_calls` cu șapte stări posibile, trei încercări implicite, pauză de 120.000 ms între ele și rezultatul apelului păstrat structurat, plus cinci funcții de server care o folosesc — inițierea apelului către curier, verificarea rezultatului, mătura pentru apelurile rămase agățate, identificarea celui care sună înapoi și webhookul de după apel. A doua implementare e filtrul de ieșire scris pentru un client din transport, care elimină recursiv câmpurile de contact ale șoferului din rezultatul uneltei, păstrând numerele dispeceratului. Rezerva, spusă înainte să întrebi: partea de telefon trece printr-o gazdă SIP, iar gazda prin care merg liniile noastre de test nu răspunde la data scrierii — nu-ți dăm un număr de demonstrație pe care nu l-am putea ridica în fața ta.
Numa empresa de transporte ou de entrega, a maioria das chamadas recebidas é a mesma pergunta feita por pessoas diferentes: onde está a mercadoria, a que horas chega, porque não chegou. A resposta não está num documento e não está num sistema — está na cabeça do motorista, que está a conduzir. O operador faz a ligação: atende a chamada do cliente, liga ao motorista, volta ao cliente. Este trabalho ocupa uma pessoa inteira e é feito cem vezes por dia, com as mesmas três frases.
Construímos exatamente esta cadeia, como mecanismo com estados, não como função de marketing. Um agente fala com o cliente. Quando precisa de uma resposta que não tem, chama uma função que inicia uma segunda chamada — para o courier — ligada à conversa de onde partiu. Essa chamada tem a sua própria linha numa tabela, com status que passa por `calling`, `in_progress`, `retrying`, `completed`, `failed`, `no_answer`, `timeout`, com o número da tentativa, com no máximo três tentativas e uma pausa de dois minutos entre elas. O resultado é escrito de forma estruturada: o resumo do que o courier disse, o tempo estimado, a posição.
A parte que é fácil de ignorar e que tratamos como requisito, não como precaução: o número de telefone do motorista não pode chegar ao cliente. Não é uma instrução escrita no prompt do agente, porque uma instrução num prompt pode ser contornada. É um filtro que percorre recursivamente o resultado da ferramenta e elimina os campos de contacto do motorista antes de esse resultado chegar ao modelo — preservando os números da central. O que foi eliminado não pode ser ditado, independentemente de como o agente seja questionado.
E a limitação mais importante é de infraestrutura, não de inteligência: um agente de voz por telefone depende de uma host SIP entre o seu operador e a plataforma. Quando essa host falha, as chamadas não saem, e a assinatura da falha é reconhecível — pedido expirado, identificador de chamada vazio, duração zero. A host por onde passam as nossas linhas de teste não responde à data de escrita desta página. Na web, o percurso de voz é verificável hoje; por telefone, a primeira etapa de qualquer trabalho é estabelecer em que host entram os seus números.
Qué incluye
Quando a resposta não está na informação que ele tem, o agente chama uma função de servidor que liga para o courier. A chamada para o courier mantém a ligação com a conversa de onde partiu, através de um identificador da conversa-pai — assim sabe-se sempre para quem se ligou e porquê. O contexto da encomenda é transmitido como estrutura, a partir do seu sistema de encomendas, não é ditado novamente.
Sete estados escritos como restrição na base de dados: `calling`, `in_progress`, `retrying`, `completed`, `failed`, `no_answer`, `timeout`. Além disso, o número da tentativa atual. A diferença entre «não respondeu» e «o sistema caiu» é visível nos dados, não adivinhada pelos registos — e isso conta quando alguém pergunta amanhã por que o cliente não recebeu uma resposta.
Por defeito: três tentativas, com 120.000 milissegundos — dois minutos — entre elas, ambas escritas como valores por defeito na tabela e na configuração do processo. Um motorista que conduz numa estrada sem sinal não responde à primeira. Um sistema que liga uma vez e declara falha é inútil exatamente no caso para o qual foi construído.
O que o courier disse é escrito como resumo, tempo estimado e posição, num campo estruturado ligado à linha da chamada. A partir daí pode seguir em frente: para o agente que fala com o cliente, para o dispatch, para o seu sistema. Um webhook depois da chamada e uma função de limpeza para as chamadas que ficaram presas completam a cadeia, para que uma chamada perdida não fique no estado `calling` para sempre.
O filtro de saída percorre recursivamente o resultado da ferramenta e elimina os campos de contacto do motorista, mantendo os números do dispatch. Está escrito no código, aplicado de forma pontual à integração onde surge o problema. O motivo é simples: a interface do fornecedor devolvia os números dos motoristas na resposta, e a política da empresa proibia que o agente os desse aos clientes. Uma instrução no prompt poderia ser contornada com uma pergunta bem formulada; um campo eliminado não pode ser contornado.
O courier que regressa com uma chamada é identificado por uma função dedicada, por isso não entra no fluxo geral de clientes e não lhe é lido o menu desde o início. Parece um detalhe; é a diferença entre um sistema que os motoristas usam e um que evitam, ligando diretamente para o dispatch, o que anula todo o trabalho.
Transferência cega por `##` e transferência assistida por `*2`, com contexto de aterragem no plano de chamadas que distingue as extensões internas de quatro dígitos dos números externos. Quando o cliente pede insistentemente uma pessoa — e em transportes pede, porque a sua carga está atrasada — a transferência não deve passar por um menu.
No percurso OpenAI Realtime: deteção semântica da fala com limiar de 0,5, almofada de 300 ms, 500 ms de silêncio, interrupção permitida por defeito. No percurso ElevenLabs, o evento de interrupção é transmitido à central para cortar a reprodução. `turn_timeout` é definido por agente. Numa chamada de transporte, onde o interlocutor está muitas vezes numa cabine ruidosa, estes limites são metade da qualidade percebida.
Não decide a rota e não reotimiza as entregas. Não dá uma tarifa se não estiver ligado à fonte que a calcula. Não sabe onde está a carga se ninguém lhe disser — nem o courier, nem o seu sistema. E não substitui o dispatch: tira-lhe as chamadas repetitivas e deixa-lhe as exceções, que são exatamente a parte pela qual é pago.
Traseul
A primeira etapa não é o cenário do agente, mas sim a telefonia: por que trunk entra o número, quem o controla, o que acontece quando o anfitrião não responde. Entregamos uma verificação escrita do percurso e, se o percurso não for seguro, dizemo-lo antes de construir algo por cima dele. Um agente excelente num anfitrião que falha é um agente que não responde.
O que o agente pergunta ao courier, em que ordem, o que faz quando o courier não responde à terceira tentativa, o que acontece quando a resposta é pouco clara, quando transfere para o despachador humano. Entregamos o cenário escrito e a lista de estados em que uma chamada pode ficar — incluindo os feios.
O contexto da encomenda vem do seu sistema e, antes de o resultado de uma ferramenta chegar ao modelo, passamos pela lista de campos que não podem sair. Entregamos a integração, a lista escrita dos campos filtrados e a prova de que o filtro se aplica ao resultado, não às instruções.
Começamos numa parte das chamadas, com a transferência para o despachador configurada de forma ampla, e lemos as transcrições. A partir daí ajustam-se os limiares de interrupção, `turn_timeout`, a formulação das perguntas e o limiar a partir do qual o agente desiste. Entregamos o relatório destas chamadas, com as decisões de ajuste, não apenas o agente iniciado.
Os dados
As regras diferem de setor para setor. Estas são as que se aplicam em transportes & logística.
Un caso
A situação
Num fluxo de entrega, a pergunta «onde está a minha encomenda» não tem resposta em nenhum sistema: a resposta está com o courier. A variante simples — o agente escreve uma mensagem ao courier e espera — falha no primeiro courier que conduz e não olha para o telefone.
Qué construimos
Construímos o despacho como tabela, não como função. Cada chamada para o courier tem uma linha com sete estados possíveis, número da tentativa, máximo de três tentativas, uma pausa de dois minutos entre elas e o resultado guardado de forma estruturada — resumo, hora estimada, posição. A linha mantém a ligação com a conversa do cliente de onde partiu. À volta da tabela: a função que inicia a chamada, a que verifica o resultado, a vassoura para as chamadas restantes presas, a identificação do courier que devolve a chamada e o webhook após a chamada.
Qué salió
Pode responder, a qualquer momento e a partir dos dados, às perguntas que um despacho recebe todos os dias: houve chamada, quantas vezes, o que respondeu, por que não houve chamada. Uma chamada perdida já não fica bloqueada num estado intermédio, porque há quem a limpe.
Qué no dice el caso
O mecanismo está escrito e migrado para a plataforma; a parte telefónica depende de um host SIP, e a que passa pelas nossas linhas de teste não responde na data da escrita. Não apresentamos o despacho como algo que você possa experimentar ligando hoje para um dos nossos números.
Perguntas
Liga. Existe uma função de servidor que inicia a chamada para o courier, ligada à conversa de onde partiu, com o contexto da encomenda transmitido como estrutura. A chamada tem a sua própria linha numa tabela, com estado, número da tentativa e resultado — portanto, pode responder-se a qualquer momento à pergunta «houve chamada, e o que disse».
Tenta-se de novo. Por omissão, três vezes, com dois minutos de intervalo, valores escritos na tabela e na configuração do processo. Se nem à terceira vez responder, a chamada fica no estado `no_answer` — um estado distinto de `failed`, que significa que algo falhou do nosso lado. Essa distinção é o motivo pelo qual vale a pena uma tabela, não um registo.
Não, e não porque lhe tenhamos dito para não o fazer. Os campos de contacto do motorista são removidos recursivamente do resultado da ferramenta antes de esse resultado chegar ao modelo. Os números do despacho ficam. O que não chega ao modelo não pode ser ditado, por mais habilmente que a pergunta seja formulada.
Pode dizer o que o courier lhe disse na última chamada, com a hora dessa chamada, ou o que lê no seu sistema, se estiver ligado a ele. O que não faz — e isso é uma decisão, não uma limitação — é estimar por si. Uma estimativa inventada por um agente torna-se numa promessa que o motorista suporta à porta.
Não hoje. A parte telefónica passa por um host SIP, e o host por onde passam as nossas linhas de teste não responde na data de escrita desta página. Não colocamos no site um número que não pudéssemos atender perante você. O percurso vocal na web é outra história: aí pode verificar-se imediatamente.
A configuração do agente aceita 32 línguas, e o romeno é a língua predefinida de um novo agente. A língua é definida por agente, portanto o agente que fala com o cliente e o que liga para o courier podem ser configurados de forma diferente. O que é preciso saber: para a síntese de voz noutras línguas além do inglês, o modelo predefinido é o rápido, e a variante de melhor qualidade é visivelmente mais lenta — o compromisso escolhe-se de forma consciente.
Pára. A deteção semântica da fala tem limiar 0,5, margem de 300 ms e 500 ms de silêncio, e a interrupção é permitida por omissão; no outro percurso, o evento de interrupção é transmitido à central para cortar a reprodução. Se um agente não pode ser interrompido, não é um problema de tom, mas de configuração — e de respostas demasiado longas.
O tempo que você definir, porque você é o operador de dados. O que você precisa saber sobre o estado atual da plataforma: a eliminação a pedido está implementada como função, e a eliminação automática no prazo, configurável por espaço de trabalho, não está — é feita por procedimento. Preferimos que saiba isto por nós, não por uma auditoria.
Não. Tira-lhe a parte repetitiva — a mesma pergunta, o mesmo telefonema, a mesma resposta — e deixa-lhe as exceções. A transferência para ele continua a ser feita com um código no teclado, e nos transportes as exceções são frequentes: mercadoria recusada, morada errada, cliente que não responde. Aí é preciso uma pessoa, e é melhor que seja uma pessoa que antes não tenha respondido a uma centena de «onde está a encomenda».
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.