När din AI har fel inför en kund
Så utformar du eskaleringsvägar, ursäkter och spårbarhet innan ditt AI-system gör sitt första publika misstag.
Ditt AI-system kommer att ha fel inför en kund. Inte för att du valde fel eller byggde dåligt, utan för att varje system som hanterar språk och bedömning i stor skala producerar en svans av dåliga svar. Frågan är inte om det händer. Frågan är om första gången det händer också är första gången någon funderar på vad man ska göra.
De flesta team upptäcker sin incidentprocess mitt under incidenten. Någon tar en skärmdump av ett felaktigt svar, den når en chef, chefen frågar vem som äger det här, och svaret dröjer två dagar. Då har kunden redan berättat för andra. Systemet är påslaget hela tiden eftersom ingen har befogenhet att stänga av det.
Det är ett helt undvikbart misslyckande, och det är ett ledningsmisslyckande snarare än ett tekniskt.
Bestäm vad "fel" betyder innan du behöver veta det
Alla felaktiga svar förtjänar inte samma respons. Gradera dem före lansering, på klarspråk, med någons namn kopplat till varje nivå.
Ett tonproblem — systemet är kortfattat, eller onödigt formellt — är en justering till nästa veckas release. Ett sakfel om en policy, ett pris eller ett leveransdatum ska åtgärdas samma dag och kunden ska kontaktas. Ett fel som rör pengar, säkerhet, ett juridiskt åtagande eller någons personuppgifter innebär att allt stannar: funktionen tas ner, och den förblir nere tills du förstår vad som hände.
Skriv ner de tre nivåerna på en sida. Ge varje nivå en ägare, en svarstid och en uttrycklig befogenhet att stänga av systemet. Den som kan dra i nödbromsen ska inte behöva leta upp en chef först. Om din enda nödbroms är en deploy har du ingen nödbroms.
Ge kunden en människa, inte en loop
Det mest skadliga mönstret i AI-driven kundservice är den slutna loopen: kunden håller inte med systemet, systemet förklarar sig igen, och det finns ingen synlig väg ut. Människor förlåter ett felaktigt svar. De förlåter inte att bli instängda.
Varje AI-driven interaktion behöver en väg till en människa som finns tillgänglig vid första förfrågan, inte vid tredje. Gör den synlig i gränssnittet, inte begravd på en hjälpsida. Dirigera den till någon som kan se hela samtalet kunden just haft, så att kunden slipper återberätta det. Och följ eskaleringsgraden som ett nyckeltal — ett system som aldrig eskalerar är oftast ett system vars utgång ingen hittar.
Sätt också ett tröskelvärde som proaktivt kopplar in en människa. Om en kund upprepar sig två gånger, om ett samtal överskrider en viss längd, om ämnet rör återbetalningar eller klagomål — lämna över utan att vänta på att bli ombedd.
Ursäkten är ett affärsbeslut
När du kontaktar en kund om ett felaktigt svar spelar tre saker roll: snabbhet, konkretion och vad du erbjuder att göra åt saken. Skriv mallen nu, medan ingen är under press.
Säg vad systemet hade fel om. Säg vad som är rätt. Säg vad ni gör för att det inte ska upprepas. Skyll inte på modellen, förklara inte arkitekturen, och använd inte uttrycket "AI-hallucination" med en kund — det låter som en ursäkt från ett företag som lanserade något det inte hade kontroll över.
Bestäm sedan kompensationspolicyn i förväg. Om systemet uppgav fel pris, står ni fast vid det? Om det lovade ett leveransdatum ni inte kan hålla, vad erbjuder ni? Svara på det i ett rum, en gång, i stället för fall för fall under press. Kostnaden för en konsekvent policy är nästan alltid lägre än kostnaden för improvisation.
Logga det du kommer att önska att du hade
Ett spårbart underlag är det som förvandlar ett gräl till en utredning. Fånga det från dag ett, för du kan inte rekonstruera det i efterhand:
- Exakt indata och exakt utdata, med tidsstämpel och ett samtals-ID som kunden kan hänvisa till
- Vilken modell och vilken version som producerade det, och vilken prompt eller konfiguration som var aktiv
- Vilka dokument eller poster systemet hämtade, så att du kan skilja en dålig källa från ett dåligt svar
- Varje mänskligt ingripande: vem som eskalerade, vem som åsidosatte, vad de ändrade
- Utfallet — löst, återbetalat, klagomål, förlorad kund
Med det följer regler för lagring och åtkomst. Bestäm hur länge ni sparar samtal, vem som får läsa dem, och hur en kund som utövar sina dataskyddsrättigheter får ett tydligt svar. En juridisk granskning före lansering är billigare än en juridisk granskning efter ett klagomål.
Öva en gång
Kör en trettio minuter lång övning innan ni går live. Ta ett troligt dåligt svar och följ det genom upptäckt, eskalering, kundkontakt och åtgärd. Ni hittar luckorna omedelbart: ingen ägare på helgerna, inget sätt att stänga av en funktion utan att stänga av alla, ingen logg över vilken promptversion som var aktiv.
Allt ovanstående är oglamoröst, och det är den del som avgör om ett felaktigt svar förblir ett felaktigt svar. Vi bygger in de här vägarna i systemen före lansering snarare än efter den första dåliga veckan — tyngden är lättare att bära när någon redan har planerat för den.