Samtalen før overføringen

Når en innringer ber taleagenten vår om å bli satt over til en bestemt person, er det enkle å ringe vedkommende og koble de to samtalene sammen. I telefoni kalles dette en "blind overføring", og det er den uhøflige varianten. Du sender en innringer videre til noen som ikke ba om samtalen, ikke aner hvem som er på linjen, og kanskje står midt i noe. Ofte tar den som blir oppringt telefonen, hører en fremmed, og innringeren må forklare seg på nytt. Resten av tiden ringer det ut, og innringeren havner tilbake der den startet, etter å ha ventet forgjeves.

En "varm overføring" er det høflige alternativet: en operatør ringer i forveien, forklarer hvem som venter og hvorfor, og kobler de to sammen bare når den som blir oppringt har sagt ja til å ta den. Vi ville ha akkurat den oppførselen, uten et menneske i midten og med en innringer som allerede er live på linjen. Så vi bygget et verktøy agentene på Hoycall, taleagentplattformen vår, kan kalle midt i samtalen: check_person_availability.

Slik fungerer det

Flyten er enkel å beskrive. Innringeren ber om å bli overført. Før den gjør noe med innringerens linje, setter agenten opp en sidesamtale til den aktuelle personen, gir én setning med kontekst om hvem som vil ha tak i dem og hvorfor, og stiller ett spørsmål: er du ledig til å ta en samtale nå? Personen svarer. Agenten kommer tilbake til den opprinnelige innringeren og enten setter dem over, eller sier at personen ikke kan ta en samtale akkurat nå.

Det interessante er at sidesamtalen selv er en KI-agent, ikke et opptak. Når verktøyet aktiveres for en virksomhet, oppretter vi en egen, spesialbygget agent for den virksomheten og hurtiglagrer ID-en. Denne indre agenten har én oppgave og en instruks som ikke gjør noe annet: levere hilsenen, stille spørsmålet om tilgjengelighet, lytte, melde en beslutning, og legge på. Den kjører på en liten, rask modell, er begrenset til godt under ett minutt, og får klar beskjed om å ikke føre en samtale. Hilsenen genereres fra caller_description som den ytre agenten sender med, så den som blir oppringt hører noe i retning av "dette er en kort samtale angående en kunde som spør om refusjon på ordre 4471, er du ledig til å ta en samtale nå?" i stedet for en kald ringelyd fra et ukjent nummer.

Begrensningen er klokka

Det vanskelige er ikke sidesamtalen. Det er at den opprinnelige innringeren sitter på linjen hele tiden mens den pågår. Hvert sekund den indre agenten bruker på å ringe, hilse og vente på svar, er et sekund med dødtid for noen som fortsatt er tilkoblet og fortsatt venter. Det setter et budsjett. Avklar spørsmålet om tilgjengelighet raskt nok til at ventetiden for den som holdes på linjen forblir tålelig, ellers er den varme overføringen verre enn den blinde den skulle erstatte.

Designproblemet ble derfor: få et pålitelig ja eller nei ut av en ekte telefonsamtale, fra ende til ende, på den tiden en person tåler stillhet. Vi ga hele operasjonen et hardt tak på rundt 35 sekunder, og brukte deretter ingeniørarbeidet på å nesten aldri nå det.

Å få svaret ut tidlig

Den naive fremgangsmåten er å sette opp samtalen, vente til den er ferdig, hente det ferdige transkriptet og lese svaret av det. Det er altfor tregt. Etterbehandlingen alene kan legge på mange sekunder etter at personen allerede har sagt "ja da, sett dem over". Vi trengte beslutningen i det øyeblikket den fantes, ikke etter at plattformen var ferdig med å rydde opp.

Resultatet er en lagdelt poller som kappløper mellom flere kilder og tar den som avklares først:

• Den indre agenten melder direkte. I det øyeblikket den har et klart svar, kaller den indre agenten et report_availability-verktøy med available, not_available eller unclear, før den i det hele tatt sier takk. Det skriver en liten oppføring polleren vår ser etter. Dette er den raske veien og den vanlige, og den lander beslutningen på omtrent tolv til femten sekunder, godt før samtalen formelt er avsluttet.
• Mønsteret i det live transkriptet. Hvis den indre agenten ikke melder rent, følger vi med på det live transkriptet etter den minste komplette utvekslingen: agenten hilser, så et menneskelig svar, så en hvilken som helst oppfølging fra agenten. Det mønsteret betyr at et ekte svar ble gitt, og plattformen publiserer det vanligvis før den endrer samtalens status. Vi analyserer det og avslutter tidlig.
• Signaler om ikke-svar. Talepostdeteksjon, ubesvart, opptatt og avvist kommer rett fra samtalemetadata. Det er ingen vits i å vente på et transkript som aldri kommer, så disse kortslutter umiddelbart til "ikke tilgjengelig".

Bare hvis alle de raske veiene forblir tause, lar polleren budsjettet løpe ut og melder at personen ikke kunne nås i tide. Når et transkript er tvetydig snarere enn fraværende, klassifiserer en liten modell det ved temperatur null i de samme tre kategoriene, så et mumlet "eh, ja, antar det" ender likevel i en beslutning og ikke en henging.

Utfallene vi godtar

Verktøyet returnerer én av tre ting, og den ytre agentens oppførsel følger av det. Sa personen ja, går agenten tilbake til innringeren og fullfører overføringen til noen som allerede vet hvem som venter og hvorfor. Sa personen nei, gikk til telepost, tok ikke telefonen, eller var opptatt, får innringeren klar beskjed om at personen ikke er tilgjengelig akkurat nå, uten å settes på lang vent for å oppdage det. Var svaret virkelig uklart, behandler vi det som et nei i stedet for å gjette, fordi å koble en innringer til noen som ikke tydelig sa ja er nettopp den feilen verktøyet finnes for å hindre.

Avveiningen vi godtok er synlig og bevisst. En varm overføring koster en ekte sidesamtale og en kort ventetid som en blind overføring ikke gjør. Til gjengjeld blir den som blir oppringt aldri overrumplet, innringeren blir aldri kastet over på noen som ikke kan snakke, og ingen bruker tretti sekunder på vent for å finne ut at personen var i et møte. For virksomhetene som kjører dette, er personen i den andre enden av overføringen som regel eieren eller en sentral ansatt, og tiden og oppmerksomheten deres er den knappe ressursen. Å spørre først, på sekunder, er hele poenget.