Når din AI tager fejl foran en kunde

Dit AI-system kommer til at tage fejl foran en kunde. Ikke fordi du har valgt forkert eller bygget dårligt, men fordi ethvert system, der håndterer sprog og vurdering i stor skala, producerer en hale af dårlige svar. Spørgsmålet er ikke, om det sker. Det er, om første gang det sker, også er første gang nogen tænker over, hvad man skal gøre.

De fleste teams opdager deres hændelsesproces midt i hændelsen. Nogen tager et skærmbillede af et forkert svar, det når en leder, lederen spørger, hvem der har ansvaret, og svaret er to dage om at komme. Til den tid har kunden fortalt det til andre. Systemet forbliver tændt hele tiden, fordi ingen har bemyndigelse til at slukke det.

Det er en fuldstændig undgåelig fejl, og det er en ledelsesfejl snarere end en teknisk.

Beslut, hvad "forkert" betyder, før du får brug for det

Ikke alle forkerte svar fortjener den samme reaktion. Inddel dem i niveauer før lancering, i klart sprog, med et navn knyttet til hvert niveau.

Et toneproblem — systemet er kortfattet eller unødigt formelt — er et coachingspørgsmål til næste uges release. En faktuel fejl om en politik, en pris eller en leveringsdato er en samme-dags-rettelse og en kundekontakt. En fejl, der berører penge, sikkerhed, en juridisk forpligtelse eller nogens personoplysninger, er en stands-produktionen-hændelse: funktionen tages ned, og den bliver nede, indtil du forstår, hvad der skete.

Skriv de tre niveauer ned på én side. Giv hvert niveau en ansvarlig, en responstid og en udtrykkelig bemyndigelse til at deaktivere systemet. Den person, der kan trække stikket, skal ikke først skulle finde en direktør. Hvis din eneste nødstopknap er en deployment, har du ingen nødstopknap.

Giv kunden et menneske, ikke en løkke

Det mest skadelige mønster i AI-baseret kundeservice er den lukkede løkke: kunden er uenig med systemet, systemet forklarer sig selv igen, og der er ingen synlig udgang. Folk tilgiver et forkert svar. De tilgiver ikke at være fanget.

Enhver AI-baseret interaktion har brug for en vej til et menneske, som er tilgængelig ved den første henvendelse, ikke den tredje. Gør den synlig i grænsefladen, ikke begravet på en hjælpeside. Send den videre til en, der kan se hele den samtale, kunden lige har haft, så kunden ikke skal fortælle det hele forfra. Og følg eskaleringsraten som et centralt nøgletal — et system, der aldrig eskalerer, er som regel et system, hvis udgang ingen kan finde.

Sæt også en tærskel, der proaktivt inddrager et menneske. Hvis en kunde gentager sig selv to gange, hvis en samtale overskrider en fastsat længde, hvis emnet berører refusioner eller klager, så overdrag uden at vente på at blive bedt om det.

Undskyldningen er en forretningsbeslutning

Når du kontakter en kunde om et forkert svar, betyder tre ting noget: hastighed, præcision og hvad du tilbyder at gøre ved det. Skriv skabelonen nu, mens ingen er under pres.

Sig, hvad systemet tog fejl om. Sig, hvad den korrekte position er. Sig, hvad du gør, for at det ikke sker igen. Læg ikke skylden på modellen, forklar ikke arkitekturen, og brug ikke udtrykket "AI-hallucination" over for en kunde — det lyder som en undskyldning fra en virksomhed, der har udsendt noget, den ikke havde kontrol over.

Beslut derefter kompensationspolitikken på forhånd. Hvis systemet har oplyst en forkert pris, honorerer I den så? Hvis det har lovet en leveringsdato, I ikke kan overholde, hvad tilbyder I så? Besvar det i et mødelokale, én gang, i stedet for sag for sag under pres. Omkostningen ved en konsekvent politik er næsten altid lavere end omkostningen ved improvisation.

Log det, du vil ønske, du havde

Et revisionsspor er det, der gør en diskussion til en undersøgelse. Opsaml det fra dag ét, for du kan ikke rekonstruere det senere:

Det præcise input og det præcise output, med et tidsstempel og et samtale-id, kunden kan henvise til
Hvilken model og hvilken version der producerede det, og hvilken prompt eller konfiguration der var i drift
Hvilke dokumenter eller registreringer systemet hentede, så du kan skelne en dårlig kilde fra et dårligt svar
Enhver menneskelig indgriben: hvem der eskalerede, hvem der tilsidesatte, hvad de ændrede
Udfaldet — løst, refunderet, klaget, kunde mistet

Dertil hører regler for opbevaring og adgang. Beslut, hvor længe I gemmer samtaler, hvem der må læse dem, og hvordan en kunde, der udøver sine datarettigheder, får et klart svar. Juridisk gennemgang før lancering er billigere end juridisk gennemgang efter en klage.

Øv det én gang

Kør en øvelse på tredive minutter, før I går i luften. Tag et sandsynligt dårligt svar, og før det gennem opdagelse, eskalering, kundekontakten og rettelsen. I finder hullerne med det samme: ingen ansvarlig i weekenden, ingen måde at deaktivere én funktion uden at deaktivere dem alle, ingen log over hvilken promptversion der var i drift.

Alt det ovenstående er uglamourøst, og det er den del, der afgør, om ét forkert svar forbliver ét forkert svar. Vi bygger disse veje ind i systemer før lancering frem for efter den første dårlige uge — vægten er lettere at bære, når nogen allerede har planlagt for den.