Balso agentas registruoja netinkamu laiku: laiko juostos, vasaros laikas ir dvigubos rezervacijos

Balso agentas registruoja netinkamu laiku. Ne visada, ne akivaizdžiai ir niekada per demonstraciją: vizitas įrašomas valanda anksčiau, skambinantysis iš Arizonos gauna laiką, kurio nėra, arba dviem žmonėms pasakoma, kad tas pats antradienis 14 val. yra jų. Kol kas nors pastebi, kad skundai susiję, kalendorius jau kelias savaites rodo netikslius duomenis ir juo niekas nebepasitiki.

Šį simptomą sukelia keturi skirtingi gedimai, ir kiekvienam reikia kito sprendimo. Toliau aprašytas kiekvienas: kokį pėdsaką jis palieka žurnale, kurios 2026 ir 2027 m. datos jį išryškins, ir testų atvejai, kuriuos dar šiandien galite paleisti per savo rezervacijų grandinę.

1. Saugomas poslinkis, o ne laiko juosta

Tai dažniausia ir sunkiausiai pastebima priežastis. Kažkur tarp to, kai modelis pasako „antradienį 14 val.“, ir to, kai įrašas atsiranda kalendoriuje, laikas paverčiamas fiksuotu poslinkiu. Viskas veikia, kol persukami laikrodžiai. Tada kiekviena būsima rezervacija, padaryta prieš persukimą, pasislenka valanda.

// what the agent extracted
{ "intent": "book", "spoken": "Tuesday at 2pm", "caller_tz": "America/New_York" }

// what got written
{ "start": "2026-03-10T14:00:00-05:00" }   // EST offset, stored on 2026-03-05

// what the calendar shows on the day
2026-03-10 13:00 EDT   // one hour early, because the zone changed on 03-08

Įrašymo metu reikšmė teisinga. Klaidinga ji tampa 2026 m. kovo 8 d., kai JAV rytinė laiko juosta pereina į UTC-4 ir išsaugotas -05:00 nebeatitinka Niujorko laiko. Rezervacija reiškia vietinį laiką konkrečioje vietoje, todėl saugoti reikia laiko juostą: America/New_York ir vietinį laiką. Į konkrečią akimirką jį skaitymo metu paverčia biblioteka, naudojanti atnaujintą laiko juostų duomenų bazę.

Datos, pagal kurias reikia testuoti, nes Europoje ir JAV jos skiriasi: JAV laikrodžiai persukami 2026 m. kovo 8 d. ir lapkričio 1 d., vėliau 2027 m. kovo 14 d. JK ir ES (taip pat ir Lietuvoje) laikrodžiai persukami 2026 m. kovo 29 d. ir spalio 25 d. Kiekvieną pavasarį maždaug tris savaites įprastas penkių valandų skirtumas tarp Londono ir Niujorko būna keturios valandos. Būtent tada rezervacijos tarp Europos ir JAV sugenda, net kai kiekviena sistema atskirai veikia teisingai.

2. Valanda, kurios nėra, ir valanda, kuri būna du kartus

Rytą, kai JAV laikrodžiai persukami į priekį, vietinis laikas 02:30 niekada neateina. Rytą, kai jie persukami atgal, 01:30 būna du kartus. Skambinantysis gali paprašyti bet kurio iš šių laikų, ir dauguma datų bibliotekų abu priims be jokio įspėjimo.

>>> datetime(2026, 3, 8, 2, 30, tzinfo=ZoneInfo("America/New_York"))
datetime.datetime(2026, 3, 8, 2, 30, tzinfo=ZoneInfo(key='America/New_York'))

>>> _.astimezone(timezone.utc)
datetime.datetime(2026, 3, 8, 7, 30, tzinfo=datetime.timezone.utc)

Jokios klaidos, jokio įspėjimo: biblioteka apskaičiavo akimirką iš laiko, kurio nebuvo. Dviprasmiškas atvejis dar blogesnis, nes abu variantai galimi. 2026 m. lapkričio 1 d. 01:30 vietos laiku būna du kartus, UTC laiku jie skiriasi valanda, ir kurį bepasirinktų Jūsų biblioteka, ji pasirinks tyliai.

Čia balso agentas turi pranašumą, kurio neturi automatinis paketinis darbas: linijoje yra žmogus. Teisingas elgesys yra pastebėti ir paklausti. Sakinį „Tą dieną tokios valandos nėra, nes persukami laikrodžiai, galiu pasiūlyti pusę dviejų arba pusę keturių“ skambinantysis priima net nepastebėjęs, kad kažkas buvo ne taip.

3. „Patikrink, tada registruok“, o tarp jų tarpas

Du skambinantieji gauna tą patį laiką, nes laisvi laikai buvo perskaityti, vyko pokalbis, o kol jis vyko, laiką jau užėmė kitas. Mūsų sukurtas administratorius taip suklydo antrą savo darbo savaitę.

[14:02:11] call_a  get_availability      -> ["14:30","15:00","15:30"]
[14:02:14] call_b  get_availability      -> ["14:30","15:00","15:30"]
[14:02:41] call_a  create_event 14:30    -> 201 Created  evt_8812
[14:02:58] call_b  create_event 14:30    -> 201 Created  evt_8813   // no conflict raised

Tarp skaitymo ir įrašymo praėjo dvidešimt devynios sekundės pokalbio, o dauguma kalendorių API be problemų sukuria persidengiantį įvykį, nes persidengiantys įvykiai leidžiami. Sprendimas yra ne ilgesnis užraktas, o pakartotinis patikrinimas įrašymo momentu. Užimtas laikas turi būti įprastas pokalbio žingsnis, o ne klaida: „šį laiką ką tik užėmė, galiu pasiūlyti pusę trijų arba ketvirtą valandą“. Jei API palaiko sąlyginį sukūrimą arba idempotentiškumo raktą, naudokite jį. Jei ne, patikrinkite dar kartą tiesiai prieš įrašydami: rizikos langas sutrumpės nuo pusės minutės iki mažiau nei sekundės.

4. Patvirtinimas sugeneruojamas, o ne paimamas iš sistemos

Blogiausias variantas, kai rezervacijos apskritai nėra. Modelis užtikrintai sudaro patvirtinimą iš to, ką ketino padaryti, įrašymas nepavyksta, o skambinantysis padeda ragelį manydamas, kad vizitas užregistruotas.

[09:41:02] tool create_event   -> 429 Too Many Requests
[09:41:02] tool result         -> {"error":"rate_limited"}
[09:41:04] assistant           -> "You're all set for Thursday at 10. See you then."

Stebėsena nieko nepastebi: skambutis baigėsi, pokalbio įrašas atrodo gerai, klientas patenkintas iki ketvirtadienio. Taisyklė, kuri to neleidžia, paprasta ir be išimčių. Patvirtinimo sakinys sudaromas tik iš rezervacijų sistemos atsakymo, niekada iš užklausos, o apie nepavykusį įrašymą skambinantysis turi išgirsti. Įvykus bet kokiai klaidai, agentas vieną kartą bando iš naujo. Jei vis tiek nepavyksta, jis pasako, kad darbuotojas patvirtins el. paštu, ir sukuria užduotį, kad taip tikrai būtų.

Prieš ką nors keisdami, paleiskite dvylika atvejų

Pridėtame faile yra dvylika rezervacijų atvejų su tikslia UTC akimirka, kurią turi duoti kiekvienas. Jos apskaičiuotos pagal laiko juostų duomenų bazę, o ne surašytos iš atminties. Atvejai apima persukimą į priekį ir atgal Europoje ir JAV, tris savaites, kai poslinkiai nesutampa, pietų pusrutulį, kur viskas vyksta atvirkščiai, ir Indijos bei Nepalo poslinkius su pusvalandžiu ir trimis ketvirčiais valandos, kurie sugadina skaičiavimus, parašytus tik sveikoms valandoms.

Kiekvieną atvejį leiskite tuo pačiu keliu, kuriuo eina skambinantysis, įskaitant modelį, o ne tiesiai į datų biblioteką. Dauguma aukščiau aprašytų klaidų atsiranda būtent ten, kur modelis perduoda laiką kodui. Du atvejai, pažymėti kaip tarpas (gap) ir dviprasmiškas (ambiguous), neturi vieno teisingo atsakymo, ir tai tyčia: tikrinate, ar Jūsų sistema pastebi ir paklausia, ar tyliai spėja.

Kada pagalbos nereikia

Jei Jūsų agentas aptarnauja vieną laiko juostą, niekada neregistruoja vizitų per vasaros laiko ribą ir rašo į kalendorių, kurio niekas kitas neliečia, trys iš šių keturių gedimų Jums negresia. Laiko juostą vis tiek saugokite: šiandien tai nieko nekainuoja, o vėliau gali kainuoti daug.

Jei matote vieną klaidingą rezervaciją apie vieną datą, paleiskite testų atvejus, pataisykite poslinkio saugojimą, ir viskas. Tai vienos popietės darbas, ir mūsų tam nereikia.

Pagalbos verta tada, kai keli šie gedimai persidengia: rezervacijos tarp laiko juostų, bendras kalendorius ir patvirtinimai, kuriais klientai jau pasitikėjo. Norint išsiaiškinti, kuris iš keturių gedimų sukėlė konkretų skundą, reikia skaityti pokalbio įrašą kartu su API žurnalu ir kalendoriaus istorija. O tokiu atveju paprastai reikia ne tik pataisyti kodą, bet ir sutvarkyti kelių mėnesių klaidingus duomenis.

Kiek kainuoja, jei taisome mes

Raštiška diagnostika kainuoja 450 €, ją pateikiame per dvi darbo dienas. Visa suma įskaitoma į tolesnius darbus, o jei diagnostika neranda priežasties, kurią galima pataisyti, pinigus grąžiname. Šio simptomo atveju paleidžiame testų atvejus per Jūsų rezervacijų grandinę, palyginame dalį tikrų skambučių su tuo, kas iš tikrųjų įrašyta kalendoriuje, ir pasakome, kuris iš keturių gedimų yra pas Jus ir kiek rezervacijų jis jau paveikė.

Kai gedimas vienas, taisymas kainuoja nuo 700 iki 1 400 €. Kai rezervacijų grandinę reikia pertvarkyti, kad joje būtų pakartotinis patikrinimas ir teisingas patvirtinimas, nuo 1 400 iki 3 700 €. Kiekvieną pataisymą perduodame kartu su testų atvejais, įtrauktais į Jūsų naujų versijų išleidimo procesą: ši klaida paprastai grįžta todėl, kad pirmą kartą jos niekas netestavo.