En hel del av det som säljs som AI i dag är en if-sats med bättre marknadsföring. Det är inget fel i det, vanlig automation är ofta rätt svar, men det är värt att veta vilket av de två man betalar för.
Frågan som avgör
Finns det en regel som alltid gäller? Då är det automation. ”När ordern passerar 30 dagar, skicka påminnelse” behöver ingen modell. Det behöver en schemalagd körning, och den är billigare, snabbare och går att testa till sista fallet.
Krävs det tolkning för att veta vad som ska hända? Då är det en agent. ”Läs mejlet, avgör om det är en reklamation, ett leveransbesked eller en ny förfrågan, och förbered rätt svar” går inte att skriva som regler utan att listan växer i all oändlighet.
Vad det kostar att välja fel
Väljer ni agent där automation räcker betalar ni för modellanrop i onödan, inför en osäkerhet som inte behövde finnas och gör felsökningen svårare. Ett skript som gör fel gör samma fel varje gång, vilket är en gåva när man letar.
Väljer ni automation där tolkning krävs får ni i stället en regelmotor som växer för varje undantag. Efter ett år är det ingen som vågar ändra i den, och varje nytt fall blir en lapp ovanpå.
Den vanligaste lösningen är en blandning
I praktiken består de flesta flöden vi bygger av båda delarna. Automation står för det som alltid gäller: hämta data, kontrollera status, skicka vidare. Agenten kliver in där det krävs tolkning, och lämnar tillbaka till automationen när beslutet är fattat.
Fördelen är att den dyra delen bara används där den behövs, och att den går att stänga av utan att hela flödet stannar.
Så gör vi bedömningen
Vi börjar med att skriva ned flödet steg för steg, som det faktiskt går till i dag. Varje steg får en etikett: regel eller bedömning. Den listan avgör arkitekturen, och den brukar också avslöja två eller tre steg som inte behöver finnas alls.
Det är i princip vad en Discovery Sprint går ut på. Vill ni veta hur det ser ut för ett av era flöden är det enklaste att boka en halvtimme och gå igenom det tillsammans.
Ett exempel ur verkligheten
En kund ville ha ”AI på inkommande mejl”. Vi skrev ned flödet och det visade sig att sjuttio procent av breven var leveransfrågor med ordernummer i ämnesraden. Den delen blev en vanlig integration mot affärssystemet, utan modell inblandad.
Resten, där kunden skriver fritt om ett problem, blev agentens uppgift. Resultatet blev billigare att driva och enklare att felsöka än om allt hade gått genom modellen, och snabbare för kunden som fick sitt leveransbesked på sekunder.
Checklista innan ni bestämmer
Går uppgiften att beskriva som regler utan att listan växer varje vecka? Finns det en tydlig indata och ett tydligt facit? Hur ofta sker den, och vad kostar ett fel? Fyra frågor, och svaren brukar peka åt samma håll.
Tänk också på vem som ska förvalta det. En regelmotor kan förvaltas av verksamheten. En agent kräver någon som förstår både flödet och modellen, och det ansvaret ska vara utpekat innan ni börjar bygga.
Vanliga frågor
Kan vi börja med automation och lägga till AI sen? Ja, och det är ofta den billigaste vägen. Bygg flödet med tydliga steg, så går det att byta ut ett enskilt steg mot en agent när behovet visar sig.
Blir det inte dyrare med två tekniker? Nej, i praktiken billigare. Modellen anropas bara där tolkning krävs, och resten körs för en bråkdel av kostnaden.
Hur vet vi att vi valt rätt? Mät andelen ärenden som går hela vägen utan människa, och hur ofta någon behöver rätta. Om regelmotorn växer med ett undantag i veckan är det dags för en agent.
Vad kostar det att byta senare? Lite, om flödet är byggt i steg. Mycket, om allt ligger i ett enda skript. Det är arkitekturbeslutet som avgör, inte tekniken i sig.