Desmit klienti, viens laiks 9:00: kā mūsu MI asistents patur piedāvāto laiku, lai izvairītos no dubultās rezervācijas

Viss sākās ar nelielu gadījumu. Potenciālajam klientam piedāvāja laiku 9:15, viņš piekrita un uzzināja, ka laiks jau ir aizņemts: cits potenciālais klients tam pašam 9:15 bija piekritis četras minūtes agrāk. Neviens nebija vainīgs. Mūsu mākslīgā intelekta (MI) asistents abiem bija piedāvājis tuvāko brīvo laiku, un to varēja saņemt tikai viens.

Tā notika ikreiz, kad pieprasījumi pienāca cits pēc cita. SMS kampaņa vecam potenciālo klientu sarakstam uzrunā ne vairāk kā 10 cilvēkus minūtē (kampaņas ir pieejamas Business plānā), tāpēc atbildes atnāk gandrīz vienlaikus. Tāpat ir ar veidlapām, kuras daudzi aizpilda pēc reklāmas palaišanas, un ar rosīgiem pirmdienas rītiem. Katra saruna, kas nonāca līdz rezervēšanas solim, saņēma vienu un to pašu informāciju: tuvākos brīvos laikus darba telpā, un aizņemti bija tikai tie, kuros jau bija rezervēta tikšanās. Tāpēc visiem piedāvāja 9:00. Pirmais „jā” šo laiku rezervēja, visi pārējie saņēma atbildi „atvainojiet, šis laiks jau ir aizņemts, varbūt der cits?”, un tieši šajā liekajā ziņu apmaiņā daļa potenciālo klientu atkrīt. Tā ir dubultā rezervācija, ko neviens kalendārs nerāda, jo kalendārs redz tikai to vienu tikšanos, kas tika rezervēta.

Tāpēc Send4 asistents tagad patur laiku, ko piedāvā, pēc noklusējuma divas stundas, un nākamajam potenciālajam klientam tiek piedāvāts nākamais brīvais laiks. Palaidiet pieprasījumu vilni zemāk vispirms ar izslēgtu paturēšanu, pēc tam ar ieslēgtu.

Kāpēc acīmredzamie risinājumi nedarbojas

Vispirms prātā nāk trīs risinājumi, un neviens no tiem nedarbojas. Piedāvāt divus laikus viena vietā nepalīdz, jo arī otrais laiks nav paturēts, un to tāpat var piedāvāt vairākiem klientiem. Tāpēc asistents rīkojas pretēji: tas piedāvā vienu laiku un jautā, vai tas der. Nepalīdz arī ļaut MI atcerēties, ko tas piedāvāja. Piedāvātais laiks pastāvēja tikai kā teksts ziņā, tāpēc sistēmā nebija nekā, ko paturēt. Bet, ja laiku rezervētu jau tad, kad to piedāvā, kalendārs piepildītos ar tikšanām, kurām neviens nav piekritis.

Laiks tiek paturēts, nevis rezervēts

Pierakstu kalendāros to sauc par pagaidu rezervāciju: laiks tiek paturēts, kamēr potenciālais klients izlemj, un nekas vēl nav rezervēts. Send4 sistēmā paturēšana ir atsevišķs ieraksts, nevis tikšanās paveids, jo citādi visam, kas lasa tikšanās, sākot ar kalendāru un beidzot ar eksportu un webhook paziņojumiem, būtu jāiemācās to izlaist.

Pēc noklusējuma paturēšana ilgst divas stundas. Ilgumu iestatāt katram rezervēšanas solim: no 0, kas paturēšanu izslēdz, līdz 24 stundām. Paturēšana beidzas agrāk, ja līdz tikšanās sākumam paliek mazāk laika, nekā prasa iestatījums Minimum notice. Ja rezervēt var ne vēlāk kā stundu iepriekš, laika plkst. 10:00 paturēšana, kas sākta plkst. 08:55, beidzas plkst. 09:00, jo pēc tam šo laiku tik un tā neviens vairs nevarētu rezervēt. Jaunas ziņas paturēšanu nepagarina, tāpēc runātīgs potenciālais klients nevar laiku aizņemt bezgalīgi. Paturēšana attiecas uz visu darba telpu, nevis uz katru pārdošanas speciālistu atsevišķi.

Paturēšana ir nesaistoša, jo mēs negribam atraidīt potenciālo klientu, kurš ir gatavs rezervēt, tā dēļ, kurš varbūt rezervēs. Kamēr ir pieejams brīvs laiks, kas nav paturēts, asistents izlaiž laikus, kas paturēti citiem potenciālajiem klientiem. Tomēr potenciālais klients, kurš lūdz tieši paturētu laiku, joprojām var to rezervēt, un laiku saņem tas, kurš pirmais apstiprina. Kad otrs potenciālais klients atkal uzraksta, asistents pasaka, ka laiks ir aizņemts, un piedāvā citu. Ja visi brīvie laiki jau ir paturēti, asistents tik un tā piedāvā tuvāko no tiem, neveidojot jaunu paturēšanu. Labāk piedāvāt laiku, uz kuru pretendē vēl kāds, nekā nepiedāvāt nevienu.

Kā izvairīties no dubultās rezervācijas: sistēmas arhitektūra

Noteikumu ir viegli noformulēt: nepiedāvāt laiku, par kuru kāds cits vēl domā. Pirmais lēmums bija neļaut MI modelim izvēlēties laikus. Laiku izvēlas sistēma, un asistentam norāda piedāvāt tieši šo laiku. Ja potenciālais klients grib citu, asistentam jāveic rīka izsaukums (tool call), kas pārceļ paturēšanu. Tā katrs laiks, ko asistents piedāvā, ir ieraksts, nevis tikai vārdi ziņā, un pēdējais vārds pieder rezervēšanas rīkam. Tālākais ir izstrādātājiem un ikvienam, kas veido pierakstu sistēmu. Plānu uzrakstījām 25. septembrī un ieviesām divas dienas vēlāk, un lielāko daļu tālāk aprakstīto robežgadījumu (edge cases) pievienoja divas plāna pārskatīšanas.

Pārtraukums starp tikšanām

Ja tikšanās ilgst 30 minūtes un pēc tās ir 10 minūšu pārtraukums, otrais potenciālais klients saņem 10:00, nevis 09:30. Ja abi piekristu, 09:30 iekristu pārtraukumā pēc pirmās tikšanās, un rezervācija tiktu noraidīta. Tāpēc no pirmās tikšanās beigām līdz nākamās sākumam jāpaliek vismaz tik daudz laika, cik ilgs ir garākais no abiem pārtraukumiem:

atstarpe starp tikšanām ≥ max(pārtraukums A, pārtraukums B)

Garākais tāpēc, ka diviem rezervēšanas soļiem var būt atšķirīgi pārtraukumi. Mainiet ilgumus un pārtraukumus zemāk un vērojiet, kur var sākties nākamā tikšanās.

Tāpat svarīgs ir tikšanās ilgums. Rezervēšanas solis var piedāvāt dažāda ilguma pakalpojumus. Kamēr potenciālais klients nav izvēlējies pakalpojumu, kalendārā tiek paturēts garākajam pakalpojumam nepieciešamais laika intervāls. Ja piedāvā 30 minūšu un 90 minūšu pakalpojumu, nākamais potenciālais klients tiek pabīdīts uz 11:00. Pēc izvēles šo intervālu pielāgo izvēlētā pakalpojuma ilgumam. Laika izvēle pārbauda sadursmes gan ar tikšanām, gan ar citiem potenciālajiem klientiem paturētajiem laikiem un patur pirmo laiku, kas der:

# Izvēlas vienu laiku, ko piedāvāt potenciālajam klientam, un to patur.
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
    # Visi brīvie laiki ir paturēti: piedāvā tuvāko, to nepaturot.
    return firstOpen(openTimes, ignoring: holds)

# Divas tikšanās saduras, ja atstarpe no vienas beigām līdz otras sākumam ir par mazu.
function clashes(a, b):
    return gap(a, b) < max(a.buffer, b.buffer)

Kad paturēšana zaudē spēku

Paturēšana ir spēkā tikai tik ilgi, kamēr saruna ir rezervēšanas solī. Saruna, kas beidzas vai pāriet uz nākamo soli, vairs neaizņem laiku, tāpēc nevienam izejas ceļam nav jāatceras sakopt pēc sevis. Kamēr kāds no jūsu komandas sarunu ir pārņēmis, tai paturēto laiku var piedāvāt arī citiem potenciālajiem klientiem, un laiku, no kura potenciālais klients atsakās, tajā pašā brīdī atkal var piedāvāt citiem.

Pirms asistents vēlreiz piedāvā paturētu laiku, tas pārbauda šo laiku pēc tiem pašiem noteikumiem kā rezervāciju. Darba laiks var mainīties, var tikt pievienota diena, kurā tikšanās nepieņem, vai kāds var rezervēt tikšanos manuāli. Laiks, kas vairs neder, tiek atbrīvots, un potenciālajam klientam piedāvā citu. Ar novēlotu „jā” ir otrādi. Ja potenciālais klients piekrīt pēc trim stundām un laiks joprojām ir brīvs, viņš saņem to pašu laiku. Asistents nepiedāvā jaunu, jo potenciālais klients piekrita konkrētam laikam, nevis jebkuram, kas ir brīvs tagad.

Testi tajā visā nepiedalās. Testa saruna scenāriju veidotājā nekad neaizņem īsta potenciālā klienta laiku, un testa rezervācija nekad neaizņem īstam potenciālajam klientam paturētu laiku.

Sacensību stāvoklis mūsu rezervāciju sistēmā

Šo kļūdu atradām pa ceļam, un tā ir klasiskā dubultās rezervācijas problēma: divas rezervācijas, kas vienā brīdī tika veiktas vienam un tam pašam tukšam laikam, varēja izdoties abas. Tas ir sacensību stāvoklis (race condition). Pārbaude pirms rezervācijas bloķēja tikšanās, kas šajā laikā jau bija, bet tukšā laikā to nav, tātad nebija ko bloķēt. Abas rezervācijas pārbaudīja laiku, abas neko neatrada, un abas saglabāja tikšanos. Mūsu MI uzdevumu rindu apstrādāja divi procesi (workers), tāpēc divus „jā” tiešām varēja apstrādāt vienā brīdī, un tikšanos tabulā nebija ierobežojuma, kas to notvertu.

To salabojām, veidojot paturēšanu. Laika izvēle un rezervēšana tagad izmanto vienu un to pašu bloķēšanu (lock), vienu katram kontam, tāpēc otrā rezervācija gaida, ierauga pirmo, un potenciālajam klientam tiek piedāvāts cits laiks. Ja bloķēšanu iegūt neizdodas, rezervācija notiek tāpat kā agrāk, jo rezervācija pēc klienta „jā” nedrīkst neizdoties mūsu kešatmiņas (cache) dēļ. Izejiet to soli pa solim zemāk bez bloķēšanas un ar to.

Ko redzat Send4

Paturētie laiki Send4 kalendārā redzami kā iesvītroti bloki ar uzrakstu „Offered to …” blakus jau rezervētajiem zvaniem. Tie nav tikšanās un netiek ieskaitīti tikšanos skaitā, un, izvēloties bloku, atveras tā saruna.

To, cik ilgi laiks tiek paturēts, iestatāt katram rezervēšanas solim. Palīdzības centrā ir norādījumi: kā tiek paturēts piedāvātais laiks.

Ko paturēšana nedara

Paturēšana ir nesaistoša, tāpēc divi potenciālie klienti joprojām var sadurties, ja viens no viņiem lūdz laiku, kas paturēts otram. Tā nav garantija. Turklāt tā zina tikai Send4 kalendāru. Vai asistents pirms laika piedāvāšanas pārbauda paša pārdošanas speciālista kalendāru?

Pagaidām ne. Rezervācijas tiek ierakstītas Send4 kalendārā.

Pieejamības katram pārdošanas speciālistam atsevišķi arī nav: katrs rezervēšanas solis piedāvā laikus, kas ir brīvi vienā kopīgā Send4 kalendārā. Un liels pieprasījumu vilnis var piepildīt visu rītu ar paturētiem laikiem, tāpēc vēlākiem potenciālajiem klientiem tiek piedāvāta pēcpusdiena vai nākamā diena. Ja tā notiek, saīsiniet paturēšanas ilgumu šajā rezervēšanas solī.

Ja norunājat zvanus ar potenciālajiem klientiem, tieši tā darbojas Send4 risinājums pārdošanas zvaniem: asistents uzdod jūsu jautājumus, patur laiku un norunā zvanu tajā pašā sarunā.