Utviklerne deres bygde produktet. Likevel bruker de timer hver uke på å forklare det samme i supportsaker, i chat og i e-post. Kodebasen, dokumentasjonen og gamle svar inneholder alt som trengs for at det meste kan besvares automatisk.
Anslagene gjelder et selskap med et etablert produkt og noen hundre kunder. I kartleggingen regner vi på deres egen saksmengde.
En assistent som leser dokumentasjonen, endringsloggen og tidligere løste saker, og skriver ferdige svar i supportsystemet. Førstelinjen godkjenner og sender. Spørsmål om funksjoner som faktisk finnes i koden, besvares med henvisning til riktig versjon i stedet for en gjetning.
ca. 35 t/mndHver utgivelse får utkast til versjonsmerknader og oppdaterte hjelpesider generert rett fra endringsloggen og kodeendringene. En utvikler leser over på minutter i stedet for å skrive fra blanke ark, og dokumentasjonen slutter å ligge tre versjoner bak.
ca. 12 t/mndInnkommende feilmeldinger grupperes mot kjente saker i feilsporingen, dubletter kobles sammen, og rapporter uten nok informasjon får et automatisk oppfølgingsspørsmål. Utviklerne møter en sortert liste, ikke en innboks.
ca. 18 t/mndDe fleste programvareselskaper tror de må rydde i dokumentasjonen før de kan automatisere support. Det er som regel omvendt. Endringsloggen, koden, lukkede saker og interne notater er allerede en presis beskrivelse av produktet. En assistent som leser disse kildene, svarer bedre enn en håndskrevet hjelpeside som ble utdatert i forrige utgivelse.
Det betyr også at andrelinjen slipper avbrytelsene. Når førstelinjen kan besvare tekniske spørsmål med belegg i koden, havner færre saker på pulten til utviklerne, og de sakene som kommer frem, er faktisk nye.
Vi analyserer de siste månedenes supportsaker: hvilke spørsmål gjentar seg, hvilke kilder svarene finnes i, og hvor utviklerne avbrytes mest.
Dokumentasjon, endringslogg og lukkede saker indekseres. Kildekoden leses der det trengs, med tilgangene deres egne regler tillater.
Assistenten skriver svar parallelt med supportteamet uten å sende noe. Vi måler hvor ofte forslaget var godt nok, mot en fasit dere setter.
Spørsmålstyper der forslagene holder mål, går over til godkjenn-og-send. Resten forblir manuelle til tallene sier noe annet.
Support og utviklere lærer å justere kilder, regler og tone selv, så løsningen følger produktet videre.
Slik bygger vi assistenter som er trygt koblet til deres egne data.
Les om AI-agenterRepeterende oppgaver ut av hendene på folk, fra e-post til rapportering.
Les om automatiseringFørstelinjesaker løst automatisk mot dokumentasjonen som allerede finnes.
Se bransjesidenMaskinoversettelse med profesjonell etterredigering, satt i system.
Se bransjesidenUsikker på hvor dere bør starte? AI-strategi gir en prioritert plan, og kurs og opplæring gjør teamet trygt på verktøyene.
Nei, oppsettet skal hindre nettopp det. Tilgang til koden styres av deres egne regler, og ingenting av det som leses inn brukes til å trene modeller hos tredjepart. Dette er noe vi avklarer og dokumenterer konkret før noe kobles til, ikke en generell forsikring.
Fordi svarene bygger på faktisk kode og dokumentasjon, er sannsynligheten lavere for at den finner opp en funksjon som ikke eksisterer, sammenlignet med en generell chatbot. Skyggemodus-piloten er nettopp der dere tester dette før noe svarer en kunde direkte.
Ja, kartleggingen starter med å se på hvor spørsmålene og kildene deres faktisk befinner seg i dag, og løsningen bygges rundt de systemene, ikke ved siden av dem.
Assistenten leser endringsloggen og kan svare med henvisning til riktig versjon, i stedet for å anta at alle kunder kjører nyeste utgave. Dette er noe vi tester spesifikt i pilotfasen hvis dere har flere versjoner i drift samtidig.
Ta med et utvalg supportsaker, så viser vi hva som kunne vært besvart automatisk. Første samtale koster ingenting.