Soluții · Transport & logistică
Dispecerizarea prin voce, construită ca mecanism, nu ca promisiune: un tabel cu stări explicite, trei încercări la două minute distanță, rezultatul apelului scris structurat și un filtru care scoate numărul șoferului din tot ce ajunge la model, ca să nu poată fi dictat clientului.
Construit dejaMecanismul 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.
Într-o firmă de transport sau de livrare, cele mai multe apeluri primite sunt aceeași întrebare pusă de oameni diferiți: unde e marfa, la ce oră ajunge, de ce nu a ajuns. Răspunsul nu e într-un document și nu e într-un sistem — e în capul șoferului, care conduce. Dispecerul face legătura: preia apelul clientului, sună șoferul, revine la client. Munca asta ocupă un om întreg și se face de o sută de ori pe zi, cu aceleași trei propoziții.
Am construit exact acest lanț, ca mecanism cu stări, nu ca funcție de marketing. Un agent vorbește cu clientul. Când are nevoie de un răspuns pe care nu îl are, cheamă o funcție care pornește un al doilea apel — către curier — legat de conversația din care a plecat. Apelul acela are propriul rând într-un tabel, cu status care trece prin `calling`, `in_progress`, `retrying`, `completed`, `failed`, `no_answer`, `timeout`, cu numărul încercării, cu maximum trei încercări și o pauză de două minute între ele. Rezultatul se scrie structurat: rezumatul a ce a spus curierul, timpul estimat, poziția.
Partea care se uită ușor și pe care noi o tratăm ca pe o cerință, nu ca pe o precauție: numărul de telefon al șoferului nu are voie să ajungă la client. Nu e o instrucțiune scrisă în promptul agentului, pentru că o instrucțiune într-un prompt se poate ocoli. E un filtru care parcurge recursiv rezultatul uneltei și elimină câmpurile de contact ale șoferului înainte ca acel rezultat să ajungă la model — păstrând numerele dispeceratului. Ce a fost eliminat nu poate fi dictat, indiferent cum e întrebat agentul.
Iar limita cea mai importantă e una de infrastructură, nu de inteligență: un agent vocal la telefon depinde de o gazdă SIP între operatorul tău și platformă. Când acea gazdă cade, apelurile nu pleacă, iar semnătura defectului e recunoscibilă — cerere expirată, identificator de apel gol, durată zero. Gazda prin care trec liniile noastre de test nu răspunde la data scrierii acestei pagini. Pe web, traseul vocal e verificabil azi; la telefon, prima etapă a oricărei lucrări e să stabilim pe ce gazdă intră numerele tale.
Ce cuprinde
Când răspunsul nu e în informația pe care o are, agentul cheamă o funcție de server care sună curierul. Apelul spre curier își păstrează legătura cu conversația din care a plecat, printr-un identificator al conversației-părinte — deci se știe întotdeauna pentru cine s-a sunat și de ce. Contextul comenzii se transmite ca structură, din sistemul tău de comenzi, nu se redictează.
Șapte stări scrise ca restricție în baza de date: `calling`, `in_progress`, `retrying`, `completed`, `failed`, `no_answer`, `timeout`. Plus numărul încercării curente. Diferența dintre „nu a răspuns” și „a căzut sistemul” e vizibilă în date, nu ghicită din jurnale — și asta contează când cineva întreabă mâine de ce nu a primit clientul un răspuns.
Implicit: trei încercări, cu 120.000 de milisecunde — două minute — între ele, ambele scrise ca valori implicite în tabel și în configurația procesului. Un șofer care conduce pe un drum fără semnal nu răspunde la prima. Un sistem care sună o singură dată și declară eșec e inutil exact în cazul pentru care a fost construit.
Ce a spus curierul se scrie ca rezumat, timp estimat și poziție, într-un câmp structurat legat de rândul apelului. De acolo poate merge mai departe: către agentul care vorbește cu clientul, către dispecerat, către sistemul tău. Un webhook de după apel și o funcție de mătură pentru apelurile rămase agățate completează lanțul, ca un apel pierdut să nu rămână în starea `calling` la nesfârșit.
Filtrul de ieșire parcurge recursiv rezultatul uneltei și elimină câmpurile de contact ale șoferului, păstrând numerele dispeceratului. E scris în cod, aplicat punctual pe integrarea unde apare problema. Motivul e simplu: interfața furnizorului întorcea numerele șoferilor în răspuns, iar politica firmei interzicea ca agentul să le dea clienților. O instrucțiune în prompt s-ar fi ocolit cu o întrebare bine formulată; un câmp eliminat nu se poate ocoli.
Curierul care revine cu un apel e identificat de o funcție dedicată, deci nu intră în fluxul general de clienți și nu i se citește meniul de la început. Pare un detaliu; e diferența dintre un sistem pe care șoferii îl folosesc și unul pe care îl ocolesc sunând direct dispecerul, ceea ce anulează întreaga lucrare.
Transfer orb prin `##` și transfer asistat prin `*2`, cu context de aterizare în planul de apelare care distinge extensiile interne de patru cifre de numerele externe. Când clientul cere insistent un om — și în transport cere, pentru că marfa lui întârzie — transferul nu trebuie să treacă printr-un meniu.
Pe traseul OpenAI Realtime: detecție semantică a vorbirii cu prag 0,5, pernă de 300 ms, 500 ms de liniște, întrerupere permisă implicit. Pe traseul ElevenLabs, evenimentul de întrerupere e transmis centralei ca să taie redarea. `turn_timeout` se stabilește per agent. Într-un apel de transport, unde interlocutorul e adesea într-o cabină zgomotoasă, pragurile astea sunt jumătate din calitatea percepută.
Nu decide ruta și nu reoptimizează livrările. Nu dă un tarif dacă nu e conectat la sursa care îl calculează. Nu știe unde e marfa dacă nimeni nu i-a spus — nici curierul, nici sistemul tău. Și nu înlocuiește dispecerul: îi ia apelurile repetitive și îi lasă excepțiile, care sunt exact partea pentru care e plătit.
Traseul
Prima etapă nu e scenariul agentului, ci telefonia: prin ce trunk intră numărul, cine îl controlează, ce se întâmplă când gazda nu răspunde. Livrăm o verificare scrisă a traseului și, dacă traseul nu e sigur, o spunem înainte de a construi ceva deasupra lui. Un agent excelent pe o gazdă care cade e un agent care nu răspunde.
Ce întreabă agentul curierul, în ce ordine, ce face când curierul nu răspunde la a treia încercare, ce se întâmplă când răspunsul e neclar, când transferă la dispecerul uman. Livrăm scenariul scris și lista de stări în care poate ajunge un apel — inclusiv cele urâte.
Contextul comenzii vine din sistemul tău, iar înainte ca rezultatul unei unelte să ajungă la model trecem prin lista câmpurilor care nu au voie să iasă. Livrăm integrarea, lista scrisă a câmpurilor filtrate și dovada că filtrul se aplică pe rezultat, nu pe instrucțiuni.
Pornim pe o parte din apeluri, cu transferul la dispecer configurat larg, și citim transcripturile. De acolo se reglează pragurile de întrerupere, `turn_timeout`, formularea întrebărilor și pragul de la care agentul renunță. Livrăm raportul acestor apeluri, cu deciziile de reglaj, nu doar agentul pornit.
Datele
Regulile diferă de la o industrie la alta. Acestea sunt cele care se aplică în transport & logistică.
Un caz
Situația
Într-un flux de livrare, întrebarea „unde e comanda mea” nu are răspuns în niciun sistem: răspunsul e la curier. Varianta simplă — agentul îi scrie curierului un mesaj și speră — pică la primul curier care conduce și nu se uită la telefon.
Ce am construit
Am construit dispecerizarea ca tabel, nu ca funcție. Fiecare apel către curier are un rând cu șapte stări posibile, numărul încercării, maximum trei încercări, o pauză de două minute între ele și rezultatul păstrat structurat — rezumat, timp estimat, poziție. Rândul păstrează legătura cu conversația clientului din care a plecat. În jurul tabelului: funcția care pornește apelul, cea care verifică rezultatul, mătura pentru apelurile rămase agățate, identificarea curierului care sună înapoi și webhookul de după apel.
Ce a ieșit
Se poate răspunde, oricând și din date, la întrebările pe care un dispecerat le primește zilnic: s-a sunat, de câte ori, ce a răspuns, de ce nu s-a sunat. Un apel pierdut nu mai rămâne blocat într-o stare intermediară, pentru că are cine să-l măture.
Ce nu spune cazul
Mecanismul e scris și migrat în platformă; partea de telefon depinde de o gazdă SIP, iar cea prin care trec liniile noastre de test nu răspunde la data scrierii. Nu prezentăm dispecerizarea ca pe ceva ce poți încerca sunând azi la un număr al nostru.
Întrebări
Sună. Există o funcție de server care pornește apelul către curier, legat de conversația din care a plecat, cu contextul comenzii transmis ca structură. Apelul are propriul rând într-un tabel, cu stare, număr de încercare și rezultat — deci se poate răspunde oricând la întrebarea „s-a sunat, și ce a zis”.
Se reîncearcă. Implicit de trei ori, la două minute distanță, valori scrise în tabel și în configurația procesului. Dacă nici a treia oară nu răspunde, apelul rămâne în starea `no_answer` — o stare distinctă de `failed`, care înseamnă că a căzut ceva la noi. Distincția asta e motivul pentru care merită un tabel, nu un jurnal.
Nu, și nu pentru că i-am spus să nu o facă. Câmpurile de contact ale șoferului sunt eliminate recursiv din rezultatul uneltei înainte ca acel rezultat să ajungă la model. Numerele dispeceratului rămân. Ce nu ajunge la model nu poate fi dictat, oricât de abil e formulată întrebarea.
Poate spune ce i-a spus curierul la ultimul apel, cu ora acelui apel, sau ce citește din sistemul tău dacă e conectat la el. Ce nu face — și e o decizie, nu o limitare — e să estimeze singur. O estimare inventată de un agent devine o promisiune pe care o suportă șoferul la ușă.
Nu azi. Partea de telefon trece printr-o gazdă SIP, iar gazda prin care merg liniile noastre de test nu răspunde la data scrierii acestei pagini. Nu punem pe site un număr pe care nu l-am putea ridica în fața ta. Traseul vocal pe web e altă poveste: acolo se poate verifica imediat.
Configurația agentului acceptă 32 de limbi, iar româna e limba implicită a unui agent nou. Limba se stabilește per agent, deci agentul care vorbește cu clientul și cel care sună curierul pot fi configurați diferit. Ce trebuie știut: pentru sinteza vocii în alte limbi decât engleza, modelul implicit e cel rapid, iar varianta de calitate mai bună e vizibil mai lentă — compromisul se alege conștient.
Se oprește. Detecția semantică a vorbirii are prag 0,5, pernă de 300 ms și 500 ms de liniște, iar întreruperea e permisă implicit; pe celălalt traseu, evenimentul de întrerupere e transmis centralei ca să taie redarea. Dacă un agent nu poate fi întrerupt, nu e o problemă de ton, ci de configurație — și de răspunsuri prea lungi.
Cât stabilești tu, pentru că tu ești operatorul de date. Ce trebuie să știi despre starea de azi a platformei: ștergerea la cerere e implementată ca funcție, iar ștergerea automată la termen, configurabilă per spațiu de lucru, nu e — se face prin procedură. Preferăm să afli asta de la noi, nu dintr-un audit.
Nu. Îi ia partea repetitivă — aceeași întrebare, aceeași sunare, același răspuns — și îi lasă excepțiile. Transferul către el rămâne la un cod din tastatură, iar în transport excepțiile sunt frecvente: marfă refuzată, adresă greșită, client care nu răspunde. Acolo e nevoie de un om, și e mai bine să fie un om care nu a răspuns înainte la o sută de „unde e coletul”.
Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.