Når KI-en din tar feil foran en kunde
Slik utformer du eskaleringsveier, unnskyldninger og revisjonsspor før KI-systemet ditt gjør sin første offentlige feil.
KI-systemet ditt kommer til å ta feil foran en kunde. Ikke fordi du valgte feil eller bygde dårlig, men fordi ethvert system som håndterer språk og skjønn i stort volum produserer en hale av dårlige svar. Spørsmålet er ikke om det skjer. Det er om første gang det skjer også er første gang noen tenker over hva som skal gjøres.
De fleste team oppdager hendelsesrutinen sin midt under hendelsen. Noen tar et skjermbilde av et feilaktig svar, det når en leder, lederen spør hvem som eier dette, og svaret bruker to dager på å komme. Da har kunden allerede fortalt det til andre. Systemet står påslått hele tiden, fordi ingen har myndighet til å slå det av.
Det er en fullt ut unngåelig svikt, og det er en ledelsessvikt snarere enn en teknisk.
Bestem hva «feil» betyr før du trenger det
Ikke alle feilsvar fortjener samme respons. Graderer dem før lansering, i klart språk, med et navn knyttet til hver grad.
Et tonefallsproblem — systemet er kortfattet, eller unødvendig formelt — er en justeringssak for neste ukes utgivelse. En faktafeil om en retningslinje, en pris eller en leveringsdato skal rettes samme dag, og kunden skal kontaktes. En feil som berører penger, sikkerhet, en juridisk forpliktelse eller noens personopplysninger er en full stopp: funksjonen tas ned, og den blir nede til du forstår hva som skjedde.
Skriv disse tre nivåene ned på én side. Gi hvert nivå en eier, en responsfrist og en uttrykkelig myndighet til å deaktivere systemet. Den som kan trekke ut kontakten, skal ikke måtte finne en leder først. Hvis din eneste nødbryter er en utrulling, har du ingen nødbryter.
Gi kunden et menneske, ikke en sløyfe
Det mest skadelige mønsteret i KI-basert kundeservice er den lukkede sløyfen: kunden er uenig med systemet, systemet forklarer seg på nytt, og det finnes ingen synlig vei ut. Folk tilgir et feilaktig svar. De tilgir ikke å bli sittende fast.
Enhver KI-basert interaksjon trenger en vei til et menneske som er tilgjengelig ved første forespørsel, ikke ved tredje. Gjør den synlig i grensesnittet, ikke gjemt bort på en hjelpeside. Rut den til noen som kan se hele samtalen kunden nettopp har hatt, slik at kunden slipper å gjenta seg. Og følg eskaleringsraten som et hovedmål — et system som aldri eskalerer, er som regel et system der ingen finner utgangen.
Sett også en terskel som utløser et menneske proaktivt. Hvis en kunde gjentar seg to ganger, hvis en samtale overstiger en fastsatt lengde, hvis temaet berører refusjoner eller klager, så overfør uten å vente på å bli bedt om det.
Unnskyldningen er en forretningsbeslutning
Når du kontakter en kunde om et feilaktig svar, er tre ting viktige: hurtighet, presisjon og hva du tilbyr å gjøre med det. Skriv malen nå, mens ingen er under press.
Si hva systemet tok feil om. Si hva som er riktig. Si hva du gjør for at det ikke skal gjenta seg. Ikke skyld på modellen, ikke forklar arkitekturen, og ikke bruk uttrykket «KI-hallusinasjon» overfor en kunde — det høres ut som en unnskyldning fra et selskap som lanserte noe det ikke hadde kontroll på.
Bestem så kompensasjonspolicyen på forhånd. Hvis systemet oppga feil pris, står dere ved den? Hvis det lovet en leveringsdato dere ikke kan holde, hva tilbyr dere? Svar på det i et møterom, én gang, i stedet for sak for sak under press. Kostnaden ved en konsekvent policy er nesten alltid lavere enn kostnaden ved improvisasjon.
Logg det du kommer til å ønske du hadde
Et revisjonsspor er det som gjør en krangel om til en undersøkelse. Fang det opp fra dag én, for du kan ikke rekonstruere det i etterkant:
- Nøyaktig inndata og nøyaktig utdata, med tidsstempel og en samtale-ID kunden kan vise til
- Hvilken modell og hvilken versjon som produserte det, og hvilken ledetekst eller konfigurasjon som var aktiv
- Hvilke dokumenter eller poster systemet hentet, slik at du kan skille en dårlig kilde fra et dårlig svar
- Hvert menneskelige inngrep: hvem som eskalerte, hvem som overstyrte, hva de endret
- Utfallet — løst, refundert, klaget, mistet kunde
Med det følger regler for lagringstid og tilgang. Bestem hvor lenge dere oppbevarer samtaler, hvem som kan lese dem, og hvordan en kunde som utøver sine personvernrettigheter får et ryddig svar. Juridisk gjennomgang før lansering er billigere enn juridisk gjennomgang etter en klage.
Øv på det én gang
Kjør en tretti minutters øvelse før dere går live. Ta et sannsynlig dårlig svar og følg det gjennom oppdagelse, eskalering, kundekontakt og retting. Dere finner hullene umiddelbart: ingen eier i helgene, ingen måte å deaktivere én funksjon uten å deaktivere alle, ingen logg over hvilken ledetekstversjon som var aktiv.
Alt over er lite glamorøst, og det er den delen som avgjør om ett feilaktig svar forblir ett feilaktig svar. Vi bygger disse veiene inn i systemene før lansering i stedet for etter den første dårlige uken — vekten er lettere å bære når noen allerede har planlagt for den.