Situacija
Panevėžio transporto įmonė, apie 90 darbuotojų, vykdo krovinių pervežimus Lietuvoje ir į Vakarų Europą. Užsakymai ateina taip, kaip patogu klientams: vieni siunčia PDF užsakymo formą, kiti – laisvą tekstą el. laiške, treti persiunčia savo sistemos išrašą su priedais. Vienos formos nėra ir nebus – klientų keliasdešimt, kiekvienas su savo įpročiais.
Du dispečerinės darbuotojai didžiąją dienos dalį skirdavo ne planavimui, o perrašinėjimui: atidaryti laišką, surasti pakrovimo ir iškrovimo adresus, datas, svorį, paletes, nuorodų numerius, suvesti į transporto valdymo sistemą, atsakyti klientui, kad užsakymas priimtas. Piko dienomis laiškai laukdavo eilėje kelias valandas, o klientai skambindavo klausti, ar užsakymas gautas.
Klaidos buvo antroji problema. Supainiotas iškrovimo laikas ar praleista pastaba apie rampos aukštį reiškė tuščią reisą arba baudą. Vadovas suskaičiavo, kad per mėnesį tokių atvejų būdavo keli, ir kiekvienas kainavo daugiau nei diena perrašinėjimo. Įmonė kreipėsi į mus su konkrečiu klausimu: ar AI gali patikimai skaityti tokius laiškus ir ar tai saugu.
Ko reikėjo
- Užsakymų iš el. pašto skaitymas nepriklausomai nuo formato: PDF, laisvas tekstas, lentelė laiške, priedai.
- Automatinis įrašo sukūrimas transporto valdymo sistemoje su visais privalomais laukais.
- Žmogaus patvirtinimas prieš kiekvieną įrašą pirmaisiais mėnesiais ir visada, kai agentas nėra tikras.
- Jokio klientų duomenų naudojimo modelio mokymui, duomenys apdorojami per API sutartomis sąlygomis.
- Įdiegimas be dispečerinės darbo sustabdymo ir be naujos programinės įrangos darbuotojams.
Ką padarėme
1–2 savaitė: laiškų analizė ir taisyklės
Pradėjome ne nuo technologijos, o nuo laiškų. Peržiūrėjome kelių mėnesių užsakymų istoriją ir sugrupavome ją pagal formatą: apie pusė atėjo kaip PDF formos, trečdalis laisvu tekstu, likusi dalis mišri. Su dispečeriais surašėme, kas yra privaloma užsakyme, kada užsakymas laikomas neaiškiu ir kam jis tokiu atveju turi keliauti. Šios taisyklės tapo agento instrukcija.
3–5 savaitė: agentas ir integracija
Agentą sukūrėme Claude modelio pagrindu per API. Agentas skaito naują laišką pašto dėžutėje, atpažįsta, ar tai užsakymas, išskaido jį į struktūrą (siuntėjas, maršrutas, laiko langai, krovinys, specialūs reikalavimai, nuorodos numeris) ir patikrina, ar visi privalomi laukai užpildyti. Jei taip – sukuria įrašo juodraštį transporto valdymo sistemoje per jos API ir pažymi laišką apdorotu. Jei ne – suformuoja trumpą santrauką, ką pavyko išskaityti ir ko trūksta, ir perduoda dispečeriui. Apie tai, kaip tokie Claude agentai veikia įmonės procesuose, rašome atskirai.
Sudėtingiausia buvo ne PDF skaitymas, o adresai: klientai rašo „pas mus į sandėlį“ arba nurodo tik miestą. Agentas tokius atvejus lygina su kliento ankstesnių užsakymų adresais ir, jei sutapimas nevienareikšmis, užsakymą siunčia žmogui, o ne spėja.
6–8 savaitė: priežiūra ir patvirtinimų atlaisvinimas
Pirmas keturias savaites kiekvieną agento sukurtą įrašą patvirtindavo dispečeris – vienu mygtuku, matydamas laišką ir išskaidytus laukus šalia. Rinkome statistiką, kur agentas klysta. Po to nuolatinių klientų standartinėms formoms patvirtinimą išjungėme, o laisvo teksto ir naujų klientų užsakymams palikome. Tai dalis mūsų procesų automatizavimo požiūrio: automatizuojama tiek, kiek pasitikėjimas pamatuotas, ne daugiau.
Rezultatas
Rankinio įvedimo laikas dispečerinėje sumažėjo apie 65 %. Matuojame paprastai: kiek užsakymų per dieną sukurta agento ir kiek žmogaus, ir kiek vidutiniškai trunka patvirtinimas. Vienas iš dviejų darbuotojų dabar daugiausia dirba su planavimu ir vežėjais, o ne su klaviatūra.
Klaidų užsakymuose sumažėjo apie 40 %. Skaičiuojame atvejus, kai įrašą teko taisyti po pakrovimo, ir tuščius reisus dėl neteisingų duomenų. Likusios klaidos dažniausiai kyla iš pačių klientų laiškų, ir agentas jas bent jau pažymi kaip nesutapimą su ankstesniais užsakymais.
Patvirtinimas klientui dabar išsiunčiamas vidutiniškai per 20 minučių nuo laiško gavimo, anksčiau piko metu tai užtrukdavo apie 2 valandas. Klientų skambučių „ar gavote“ beveik nebeliko.
Bijojome, kad AI pridarys klaidų, kurias pastebėsime tik rampoje. Išėjo atvirkščiai: agentas pirmas pamato, kai klientas atsiuntė kitokią datą nei prieš savaitę.
Ką patartume panašioje situacijoje
- Pradėkite nuo laiškų istorijos, ne nuo modelio pasirinkimo. Taisyklės, ką laikyti neaiškiu užsakymu, yra svarbiausia sistemos dalis.
- Žmogaus patvirtinimą palikite nuo pirmos dienos ir atlaisvinkite tik ten, kur statistika rodo, kad agentas neklysta.
- Integruokite į esamą sistemą per API, o ne kurkite naują darbo vietą – darbuotojai turi matyti rezultatą ten, kur dirba.
- Susitarkite dėl duomenų: kur apdorojami, kiek saugomi, kad nenaudojami mokymui. Tai klausimas, kurį jūsų klientai užduos pirmieji.
