Hva hindrer AI-en i å love noe dere ikke kan holde?

Nesten alle vi snakker med ender opp med det samme spørsmålet, og det er sjelden det vi hadde forberedt oss på. Det handler ikke om AI-en forstår hva kunden mener. Det handler om hva den sier når ingen sitter ved siden av og følger med.

Det er en rimelig bekymring. En ansatt som er usikker, spør en kollega. En språkmodell som er usikker, skriver en setning likevel, og den høres nøyaktig like sikker ut som alle andre setninger den skriver. Derfor hviler hele konstruksjonen på ett utgangspunkt: vi stoler ikke på at modellen velger riktig. Vi bygger slik at det gale svaret ikke er mulig å gi.

Her er de viktigste sperrene, uten teknikkprat.

En booking er enten ekte eller ingen booking

Kim finner aldri opp en ledig tid. Når noen spør etter en tid, går spørsmålet til bookingsystemet deres, og Kim får bare tilby de tidene som kom tilbake derfra. Det finnes ingen vei rundt: en tid systemet ikke har sagt ja til, kan ikke havne i en setning.

Sier kunden ja, blir bookingen skrevet inn på ordentlig, rett inn i systemet dere allerede jobber i. De ansatte ser den der de alltid ser. Det finnes ingen egen liste hos oss som noen må huske å avstemme.

Og hvis bookingsystemet deres ikke svarer? Da sier Kim at en kollega må ta over, og et menneske gjør det. Kim sier aldri "det er dessverre fullbooket" i den situasjonen. Den er verdt å stoppe ved, for det er en sperre som koster oss noe: det ville vært mer bekvemt å la AI-en gjette. Men et system som bare er utilgjengelig en stund, ser helt likt ut som et fullbooket, og forskjellen er at det første ville fått Kim til å avvise hver eneste kunde i flere dager mens alt så rolig og grønt ut. Et stille avbrudd koster alltid mer enn et synlig.

To gjester kan ikke få samme tid

To personer kan ta kontakt i samme sekund. Én ringer, én skriver i chatten, begge spør om torsdag klokka sju.

Derfor håndteres bookingene én om gangen per avdeling. Plassen telles om i samme øyeblikk som bookingen skrives, ikke noen sekunder før, så det finnes ikke noe glipp der den andre samtalen rekker å komme imellom. Skurrer nettet og samme booking sendes to ganger, blir det likevel én booking, ikke to.

Det der har ingenting med AI å gjøre. Det er håndverk, og det er forskjellen mellom noe som snakker om bookinger og noe som utfører dem.

Reglene deres er regler, ikke forslag

Stengte datoer, hvor kort varsel dere godtar, minste selskap, hvor store selskaper som skal tas av et menneske i stedet: alt slikt stiller dere inn selv i portalen.

Det viktige er hvor reglene ligger. De ligger utenfor AI-en. De er ikke en instruks Kim blir bedt om å følge, men et vilkår som prøves før en booking kan bli noe av. Ingen kunde kan snakke seg forbi dem, uansett hvor vennlig eller iherdig de spør, og de gjelder likt på telefon, chat, SMS og e-post. Det er også derfor de bare må stilles inn én gang.

Vi kontrollerer i etterkant at Kim gjorde det Kim sa

Dette er sperren vi er mest fornøyd med, og den bygger på en ubehagelig innsikt: før eller siden kommer en språkmodell til å si "da legger jeg det inn" uten at noen booking ble av. Alle modeller gjør det iblant. Det er ikke noe man prompter seg bort fra.

Så vi går ut fra at det skjer. Etter hver samtale sammenlignes det Kim faktisk sa, med hva som finnes i systemet. Høres det ut som en booking ble gjort, og det ikke finnes noen booking, utløses et varsel og et menneske hos dere får vite det med én gang.

Kunden rakk å legge på fornøyd. Dere får likevel vite det samme dag, i stedet for når noen står i døra til et bord som ikke finnes. Kontrollen er bevisst uavhengig av hvilken AI-modell som brukes, så den fortsetter å virke den dagen vi bytter modell.

Og hvis dere selv skriver inn noe feil?

Nesten alt Kim kan si, kommer fra dere: åpningstidene deres, menyen deres, prisene deres, de vanlige spørsmålene deres. Det er styrken, og det er selvsagt også risikoen.

Fire ting gjelder der.

Kim siterer dere, Kim husker ikke. En pris, en tid eller en regel må komme fra opplysningene deres der og da. Kim får ikke si et tall som ikke er hentet fram, uansett hvor rimelig det høres ut, eller hvor sikkert modellen "tror" den vet.

Mangler svaret, blir hullet ikke fylt igjen. Står det ingenting om saken, kobler Kim heller over til et menneske, og spørsmålet havner samtidig i en liste i portalen, så dere ser hva kundene faktisk spør om som dere ikke har svar på. Den listen er som regel det nyttigste dere får ut av den første måneden.

Deres egne instruksjoner ligger under sikkerhetsreglene, aldri over. Dere kan be Kim være mer selgende, hilse på en bestemt måte eller alltid nevne helgetilbudet. Dere kan ikke, ikke engang ved et uhell, formulere en instruks som får Kim til å booke uten å sjekke, eller gjette i stedet for å koble over. Den rekkefølgen kan ikke snus fra portalen.

Kim tar heller ikke ordre fra den som skriver inn. En melding som prøver å få Kim til å endre atferd eller røpe instruksjonene sine, blir ikke fulgt. Og Kim spør aldri etter fødselsnummer, passord, BankID-koder eller kortnumre, uansett hvem som ber om det.

Hva vi ikke lover

Det bør sies rett ut, for leverandører pleier å hoppe over det.

Sperrene styrer hva Kim får gjøre, ikke hva Kim vet. Står det feil åpningstider i portalen, kommer Kim til å si feil åpningstider, like høflig og like sikkert som alt annet. Ingen teknologi i verden leser virksomheten deres bedre enn dere selv gjør.

Det vi går god for, er snevrere, og det er den delen som er til å stole på: Kim finner ikke på noe utover det dere har gitt, og påstår aldri at noe er gjort som ikke er gjort. Feil i opplysningene deres blir gale svar. Feil i teknikken vår skal ikke bli en booking som ikke finnes.

Det er den forskjellen hele bygget hviler på, og det er den vi helst blir vurdert på.

Vil dere høre hvordan det låter i praksis, book en demo, så setter vi opp Kim på deres egen informasjon.