Deset poptávek, jeden termín v 9:00: jak náš AI asistent podrží nabídnutý termín a pomáhá vyhnout se dvojité rezervaci

Začalo to jedním drobným případem. Zákazník dostal nabídku na 9:15, souhlasil a dozvěděl se, že termín už je pryč: jiný zákazník souhlasil se stejným termínem o čtyři minuty dřív. Nikdo neudělal chybu. Náš asistent založený na umělé inteligenci (AI) nabídl oběma nejbližší volný termín a dostat ho mohl jen jeden z nich.

Stávalo se to pokaždé, když poptávky přišly krátce po sobě. SMS kampaň na starší poptávky zahájí nejvýš 10 konverzací za minutu (kampaně jsou v tarifu Business), takže odpovědi chodí ve vlnách. Stejně tak chodí formuláře vyplněné po spuštění reklamy nebo v pondělí ráno, kdy je nejrušněji. Každá konverzace, která došla ke kroku domlouvání termínu, dostala stejné podklady: nejbližší volné termíny v pracovním prostoru, přičemž za obsazené se počítaly jen domluvené schůzky. Všichni proto dostali nabídku na 9:00. První „ano“ termín získalo a všichni ostatní slyšeli: „Bohužel, ten už je obsazený. Nehodil by se jiný?“ A právě při tomhle dalším kole zpráv zákazníci odpadají. Je to dvojitá rezervace, kterou žádný kalendář neukáže, protože kalendář vidí jen tu jednu schůzku, která se opravdu domluvila.

Asistent Send4 proto teď nabídnutý termín podrží, ve výchozím nastavení na dvě hodiny, a dalšímu zákazníkovi nabídne další volný termín. Pusťte si nával poptávek níže nejdřív s vypnutým podržením a pak se zapnutým.

Proč zjevná řešení nefungují

Jako první napadnou tři řešení a žádné z nich nefunguje. Nabídnout místo jednoho termínu dva nepomůže, protože ani druhý termín není podržený a koliduje úplně stejně. Šli jsme proto opačnou cestou: asistent nabízí jeden termín jako otázku, na kterou stačí odpovědět ano, nebo ne. Nepomůže ani to, aby si AI pamatovala, co nabídla. Nabídnutý termín existoval jen jako text ve zprávě, takže ho nic nemohlo zablokovat. A kdybychom termín rovnou zapsali jako schůzku, kalendář by se zaplnil schůzkami, se kterými nikdo nesouhlasil.

Podržení není domluvená schůzka

V kalendářích se tomu obvykle říká předběžná rezervace: termín zůstává stranou, dokud se zákazník rozhoduje, a schůzka zatím není potvrzená. V Send4 je podržení samostatný záznam, ne druh schůzky. Kdyby to byl druh schůzky, muselo by se ho naučit přeskakovat všechno, co se schůzkami pracuje, od kalendáře po exporty a webhooky.

Podržení trvá ve výchozím nastavení dvě hodiny. Délku nastavíte u každého kroku domlouvání termínu, od 0, což podržení vypne, až po 24 hodin. Skončí dřív, když se termín přiblíží natolik, že by už nesplnil minimální předstih. Při předstihu jedné hodiny vyprší podržení termínu v 10:00, které začalo v 8:55, už v 9:00, protože potom by si ho stejně nikdo domluvit nemohl. Další zprávy podržení neprodlužují, takže upovídaný zákazník si termín nemůže držet donekonečna. Podržení platí v celém pracovním prostoru, ne pro jednotlivé obchodníky.

Podržení je jen předběžné, protože nechceme odmítnout zákazníka, který je připravený si termín domluvit, kvůli jinému, který se teprve rozhoduje. Dokud je k dispozici volný termín, který nikdo nedrží, asistent termíny podržené pro jiné zákazníky přeskakuje. Zákazník, který si řekne přesně o podržený termín, si ho ale domluvit může a dostane ho ten, kdo potvrdí jako první. Až druhý zákazník příště napíše, asistent mu řekne, že termín už je pryč, a nabídne jiný. Když je podržený každý volný termín, asistent nabídne ten nejbližší i tak, aniž by vytvořil další podržení. Nabídnout termín, o který stojí i někdo jiný, je lepší než nenabídnout žádný.

Jak se vyhnout dvojité rezervaci: návrh systému

Pravidlo se řekne snadno: nenabízet termín, o kterém se rozhoduje někdo jiný. Jako první jsme se rozhodli, že termíny nebude vybírat AI model. Termín vybere náš kód a asistent dostane pokyn nabídnout přesně ten. Když zákazník chce jiný, asistent musí zavolat nástroj (tool call), který podržení přesune. Každý termín, který navrhne, je tak záznam, ne jen slova ve zprávě. Poslední slovo má nástroj, který schůzku domlouvá. Zbytek je pro vývojáře a pro každého, kdo sám vytváří rezervační systém. Plán jsme sepsali 25. září, o dva dny později bylo hotovo a většinu okrajových případů (edge cases), které popisujeme níže, přidaly dvě revize plánu.

Pauza mezi schůzkami

Při 30minutových schůzkách a 10minutové pauze dostane druhý zákazník nabídku na 10:00, ne na 9:30. Kdyby oba souhlasili, schůzka v 9:30 by začínala ještě v pauze po první schůzce a rezervace by se zamítla. Mezi koncem první schůzky a začátkem další proto musí být mezera alespoň tak dlouhá jako delší z obou pauz:

mezera mezi schůzkami ≥ max(pauza A, pauza B)

Delší z obou proto, že dva kroky domlouvání termínu mohou mít různě dlouhé pauzy. Posuňte níže délky schůzek a pauz a sledujte, kde může začít další schůzka.

Stejně tak záleží na délce schůzky. Krok domlouvání termínu může nabízet služby různé délky. Dokud si zákazník službu nevybere, držíme v kalendáři časový úsek pro nejdelší z nich. Služba na 30 minut a služba na 90 minut tak posunou dalšího zákazníka na 11:00. Po výběru úsek upravíme podle délky zvolené služby. Výběr termínu hlídá kolize termínů: každý termín porovná se schůzkami i s podrženími ostatních zákazníků a podrží první, který kontrolou projde:

# Vybere jeden termín, který nabídne zákazníkovi, a podrží ho.
function offerTime(lead):
    for time in openTimes(after: now + minimumNotice):
        if clashes(time, meetings): continue
        if clashes(time, holdsOfOtherLeads): continue
        hold(time, lead, until: earliest(now + holdLength, time − minimumNotice))
        return time
    # Všechny volné termíny jsou podržené: nabídne nejbližší i tak, bez podržení.
    return firstOpen(openTimes, ignoring: holds)

# Dvě schůzky jsou v kolizi, když je mezera mezi koncem jedné a začátkem druhé příliš malá.
function clashes(a, b):
    return gap(a, b) < max(a.buffer, b.buffer)

Kdy podržení přestane platit

Podržení platí jen tak dlouho, dokud je jeho konverzace v kroku domlouvání termínu. Jakmile konverzace skončí nebo přejde k dalšímu kroku, termín přestane blokovat, takže žádná z cest, kterými konverzace krok opouští, nemusí po sobě uklízet. Když konverzaci převezme někdo z vašeho týmu, podržený termín se může nabízet i dalším zákazníkům. A termín, který zákazník odmítne, se v tu chvíli znovu uvolní k nabízení.

Než asistent podržený termín nabídne znovu, ověří ho podle stejných pravidel jako rezervaci. Pracovní doba se mohla změnit, mohl přibýt zablokovaný den nebo mohl někdo domluvit schůzku ručně. Termín, který už nevyhovuje, se uvolní a zákazník dostane nabídku jiného. Pozdní „ano“ funguje obráceně. Když zákazník souhlasí o tři hodiny později a termín je pořád volný, dostane přesně ten termín. Asistent ho nevymění za nový, protože zákazník souhlasil s konkrétním termínem, ne s čímkoli, co je zrovna volné.

Testy do toho vůbec nezasahují. Testovací konverzace v editoru scénářů nikdy nezabere termín skutečného zákazníka a schůzka domluvená v testu nikdy nezabere termín podržený pro skutečného zákazníka.

Souběh (race condition) v našem rezervačním systému

Na tuhle chybu jsme narazili cestou a je to učebnicový problém dvojité rezervace (double booking problem): dvě rezervace stejného volného termínu ve stejném okamžiku mohly projít obě. Kontrola před rezervací zamykala schůzky, které už v daném termínu byly, a volný termín žádné nemá, takže nebylo co zamknout. Obě rezervace termín zkontrolovaly, obě nic nenašly a obě uložily schůzku. Frontu úloh pro AI obsluhovaly dva pracovní procesy (workers), takže dvě „ano“ se opravdu mohla zpracovat ve stejném okamžiku, a tabulka schůzek neměla žádné omezení (constraint), které by to zachytilo.

Opravili jsme to, když jsme stavěli podržení. Výběr termínu i rezervace teď používají stejný zámek (lock), jeden na účet, takže druhá rezervace počká, uvidí tu první a zákazník dostane nabídku jiného termínu. Když zámek získat nejde, rezervace proběhne stejně jako dřív, protože zákazníkovo „ano“ nesmí nikdy selhat kvůli naší mezipaměti (cache). Projděte si to níže krok za krokem bez zámku a se zámkem.

Co uvidíte v Send4

Podržené termíny se v kalendáři Send4 zobrazují jako šrafované bloky „Offered to …“ vedle už domluvených hovorů. Nejsou to schůzky a jako schůzky se nepočítají. Kliknutím na blok otevřete jeho konverzaci.

Jak dlouho se termín podrží, nastavíte u každého kroku domlouvání termínu. Postup najdete v nápovědě: jak funguje podržení nabízených termínů.

Co podržení nedělá

Podržení je jen předběžné, takže se dva zákazníci pořád mohou sejít na stejném termínu, když si jeden z nich řekne o termín podržený pro druhého. Není to záruka. Navíc počítá jen s kalendářem Send4. Kontroluje asistent před nabídnutím termínu vlastní kalendář obchodníka?

Zatím ne. Domluvené hovory se zapisují do kalendáře Send4.

Nedá se ani nastavit dostupnost jednotlivých obchodníků: každý krok domlouvání termínu nabízí termíny, které jsou volné v jediném kalendáři Send4. A velký nával poptávek může podrženími zaplnit celé dopoledne, takže pozdější zákazníci dostanou nabídku na odpoledne nebo na další den. Když se to stane, zkraťte podržení v daném kroku domlouvání termínu.

Pokud se zákazníky domlouváte hovory, přesně tohle v Send4 umí domlouvání obchodních schůzek: asistent se zákazníka zeptá na to, co potřebujete vědět, podrží termín a domluví hovor v jedné konverzaci.