Situācija
Pārvadājumu uzņēmums Panevēžā ar aptuveni 90 darbiniekiem pārvadā kravas Lietuvā un uz Rietumeiropu. Pasūtījumi nāk tā, kā klientiem ērti: daži sūta PDF pasūtījuma veidlapu, citi – brīvu tekstu e-pastā, vēl citi pārsūta izvilkumu no savas sistēmas ar pielikumiem. Vienota formāta nav, un tāda arī nebūs: uzņēmumam ir vairāki desmiti klientu, katram savi ieradumi.
Divi dispečeru biroja darbinieki lielāko dienas daļu pavadīja nevis plānojot, bet pārrakstot: atvēra e-pastu, atrada iekraušanas un izkraušanas adreses, datumus, svaru, paletes un atsauces numurus, ievadīja tos transporta pārvaldības sistēmā un atbildēja klientam, ka pasūtījums saņemts. Noslogotās dienās e-pasti rindā gaidīja vairākas stundas, un klienti zvanīja un jautāja, vai pasūtījums ir saņemts.
Kļūdas bija otra problēma. Sajaukts izkraušanas laiks vai nepamanīta piezīme par rampas augstumu nozīmēja tukšu reisu vai sodu. Vadītājs aprēķināja, ka šādu gadījumu mēnesī ir daži un katrs izmaksā vairāk nekā dienas pārrakstīšanas darbs. Uzņēmums vērsās pie mums ar konkrētu jautājumu: vai AI var droši nolasīt šādus e-pastus un vai tas ir drošs?
Kas bija nepieciešams
- Pasūtījumu nolasīšana no e-pasta neatkarīgi no formāta: PDF, brīvs teksts, tabula e-pastā, pielikumi.
- Automātiska ieraksta izveide transporta pārvaldības sistēmā ar visiem nepieciešamajiem laukiem.
- Cilvēka apstiprinājums pirms katra ieraksta pirmajos mēnešos un vienmēr, kad aģents nav drošs.
- Klientu datus neizmanto modeļu apmācībai; dati tiek apstrādāti caur API saskaņotos noteikumos.
- Ieviešana bez dispečeru biroja darba apturēšanas un bez jaunas programmatūras darbiniekiem.
Ko mēs darījām
1.–2. nedēļa: e-pastu analīze un noteikumi
Sākām nevis ar tehnoloģiju, bet ar e-pastiem. Pārskatījām vairāku mēnešu pasūtījumu vēsturi un sagrupējām to pēc formāta: aptuveni puse nāca kā PDF veidlapas, trešdaļa – kā brīvs teksts, pārējie bija jaukti. Kopā ar dispečeriem pierakstījām, kas pasūtījumā ir obligāts, kad pasūtījumu uzskata par neskaidru un kam tas šādā gadījumā jānodod. Šie noteikumi kļuva par aģenta instrukcijām.
3.–5. nedēļa: aģents un integrācija
Aģentu izveidojām uz Claude modeļa, izmantojot API. Aģents nolasa jaunu e-pastu pastkastē, atpazīst, vai tas ir pasūtījums, sadala to struktūrā (sūtītājs, maršruts, laika logi, krava, īpašās prasības, atsauces numurs) un pārbauda, vai visi obligātie lauki ir aizpildīti. Ja ir, tas caur API izveido ieraksta melnrakstu transporta pārvaldības sistēmā un atzīmē e-pastu kā apstrādātu. Ja nav, tas uzraksta īsu kopsavilkumu par to, ko izdevās nolasīt un kas trūkst, un nodod to dispečeram. Atsevišķi rakstām par to, kā šādi Claude aģenti darbojas uzņēmuma procesos.
Grūtākais bija nevis PDF nolasīšana, bet adreses: klienti raksta „uz mūsu noliktavu” vai norāda tikai pilsētu. Aģents šādus gadījumus salīdzina ar adresēm no klienta iepriekšējiem pasūtījumiem, un, ja atbilstība ir neviennozīmīga, tas pasūtījumu nodod cilvēkam, nevis minē.
6.–8. nedēļa: uzraudzība un apstiprinājumu atvieglošana
Pirmās četras nedēļas katru aģenta izveidoto ierakstu apstiprināja dispečers ar vienu pogu, redzot e-pastu un nolasītos laukus blakus. Vācām statistiku par to, kur aģents kļūdās. Pēc tam atslēdzām apstiprināšanu standarta veidlapām no regulāriem klientiem un saglabājām to brīvā teksta pasūtījumiem un jauno klientu pasūtījumiem. Tā ir daļa no mūsu procesu automatizācijas pieejas: automatizēt tik tālu, cik uzticība ir izmērīta, un ne tālāk.
Rezultāts
Manuālās ievades laiks dispečeru birojā samazinājās aptuveni par 65 %. To mērām vienkārši: cik pasūtījumu dienā izveidoja aģents un cik cilvēks un cik ilgi vidēji aizņem apstiprināšana. Viens no diviem darbiniekiem tagad galvenokārt strādā pie plānošanas un ar pārvadātājiem, nevis pie tastatūras.
Kļūdas pasūtījumos samazinājās aptuveni par 40 %. Skaitām gadījumus, kad ieraksts pēc iekraušanas bija jālabo, un tukšos reisus datu kļūdu dēļ. Atlikušās kļūdas pārsvarā rodas paša klientu e-pastos, un aģents vismaz atzīmē tās kā neatbilstību iepriekšējiem pasūtījumiem.
Apstiprinājums klientam tagad tiek nosūtīts vidēji 20 minūšu laikā pēc e-pasta saņemšanas; agrāk noslogotos laikos tas aizņēma aptuveni 2 stundas. Klientu zvani ar jautājumu „vai saņēmāt” gandrīz pazuduši.
Baidījāmies, ka AI pieļaus kļūdas, ko pamanīsim tikai pie iekraušanas rampas. Izrādījās otrādi: aģents pirmais pamana, ka klients atsūtījis citu datumu nekā pirms nedēļas.
Ko mēs ieteiktu līdzīgā situācijā
- Sāciet no e-pastu vēstures, nevis no modeļa izvēles. Noteikumi par to, ko uzskatīt par neskaidru pasūtījumu, ir svarīgākā sistēmas daļa.
- Saglabājiet cilvēka apstiprinājumu no pirmās dienas un atvieglojiet to tikai tur, kur statistika rāda, ka aģents nekļūdās.
- Integrējieties ar esošo sistēmu caur tās API, nevis veidojiet jaunu darba vietu: darbiniekiem rezultāts jāredz tur, kur viņi jau strādā.
- Vienojieties par datu noteikumiem: kur tie tiek apstrādāti, cik ilgi glabāti un ka netiek izmantoti apmācībai. Tas ir jautājums, ko jūsu klienti uzdos pirmo.
