AI-programvare for kundeservice: Hold svarene oppdatert

Leveringspolicyen din endres. Nettstedet gir nå riktig svar, men en gammel FAQ-oppføring og supportsvar fra forrige måned beskriver fortsatt den tidligere prosessen. Før du lar AI-programvare for kundeservice svare på neste spørsmål, må du vite hvilke kilder som er endret, og hvilke svar som fortsatt må gjennomgås.

Denne veiledningen dekker vedlikehold av kunnskapsgrunnlaget etter lansering: hvordan du håndterer en policyendring, avklarer motstridende svar og gir teamet ditt en tydelig beslutning om lansering. Dette er en operasjonell sjekkliste, ikke en sammenligning av produkter. Hvis du fortsatt velger programvare, kan du begynne med den praktiske evalueringsveiledningen.

Begynn med en endringslogg, ikke et omskrevet svar

Når den policyansvarlige kunngjør en endring, bør du registrere hva som er endret før du redigerer supportinnholdet. Et gjennomarbeidet svar er ikke klart for kundene hvis ingen har bekreftet når det gjelder. Oppbevar denne loggen i det eksisterende delte dokumentet eller oppgaveverktøyet; det krever ikke et nytt verktøy.

Registrer hvem som eier policyen, ikrafttredelsesdatoen, hvilke kunder eller produkter som berøres, den tidligere regelen og den nye regelen. Legg til eventuelle unntak og personen som kan avklare dem. Koble loggen til det autoritative policydokumentet, slik at en gjennomgåer kan kontrollere beslutningen i stedet for å basere seg på en videresendt melding.

Se for deg for eksempel at virksomheten din går fra returforespørsler via e-post til et returskjema. Angi om utestående forespørsler fortsatt skal håndteres via e-post, og om skjemaet gjelder for alle produkter. Dette er illustrerende spørsmål, ikke en policy fra Deskhero. Uten disse detaljene kan to ulike svar begge høres fornuftige ut, samtidig som de sender den samme kunden til forskjellige steder.

Spor det endrede svaret på tvers av kildene

Søk etter den gamle formuleringen, det gamle målet og vanlige omskrivinger. Se lenger enn siden som kunngjorde endringen. En kunde kan spørre hvordan de starter en retur, hvor de skal sende en returforespørsel, eller om en tidligere forespørsel fortsatt er gyldig. Behandle dette som én kunnskapsoppdatering med flere innganger.

Lag en kort kildeoversikt. For hvert element registrerer du plassering, tiltenkt målgruppe, eier og nødvendige tiltak. Nyttige tiltak kan være å oppdatere instruksjonen, fjerne en duplikat, merke en historisk referanse eller be den policyansvarlige avgjøre en konflikt.

• Offentlige FAQ-svar: kontroller hovedsvaret og relaterte spørsmål som omtaler den samme prosessen.
• Intern kunnskap: oppdater instruksjoner for unntak og eskalering, i tillegg til standardsvaret.
• Nettstedssider: undersøk hjelpetekst og andre sider som gjentar den gamle instruksjonen.
• Svarmaler: erstatt lagret tekst som teamet fortsatt kan sende manuelt.
• Historiske samtaler: identifiser gamle eksempler som krever ekstra grundig kontroll hvis de brukes som grunnlag for et nytt utkast.

Ikke skriv om historiske kundesamtaler for å få dem til å se aktuelle ut. Bevar oversikten over det som faktisk skjedde. Dokumenter i stedet den gjeldende regelen tydelig, og be gjennomgåere se etter utdaterte instruksjoner i nye svar. I Deskhero fjernes eller avvises et offentlig FAQ-svar fra automatiske svar, mens tidligere saker fortsatt brukes som grunnlag for svarutkast. Derfor bør gjennomgåere se etter utdatert ordlyd i utkastene.

Skill offentlige svar fra interne behandlingsinstruksjoner

Skriv kundesvaret med utgangspunkt i handlingen kunden kan utføre. Plasser unntak som bare gjelder ansatte, godkjenningstrinn og undersøkelsesnotater i interne instruksjoner. Ikke gjør en hel intern samtale om til en offentlig FAQ bare fordi den inneholder et nyttig svar.

Dette skillet er viktig i Deskhero fordi kunnskapen som er tilgjengelig for gjennomgåtte utkast, skiller seg fra kunnskapen som brukes til automatiske svar. Deskhero-svarutkast bygger på kunnskap i arbeidsområdet, inkludert FAQ-innhold, intern kunnskap, innhentede nettsider og tidligere saker. Brukerne gjennomgår og sender disse utkastene. Chatboten og de valgfrie automatiske e-postsvarene svarer bare ut fra den godkjente offentlige FAQ-en, og du kan slå dem på når 100 FAQ-svar er godkjent. Spørsmål som ligger utenfor denne kunnskapen, sendes til en person.

Bruk dette skillet til å definere omfanget av gjennomgangen: undersøk brede kunnskapskilder for å sikre god kvalitet på utkastene, og undersøk godkjente offentlige svar for kundevendt automatisering. Oversikten over Deskhero-programvare for AI-kundeservice forklarer hvordan disse arbeidsflytene henger sammen hvis du trenger å knytte vedlikeholdsprosessen din til produktet.

Skriv om svaret uten å skjule unntaket

For hver berørte FAQ-oppføring bør du utarbeide en fullstendig erstatning i stedet for å legge til en korrigering under motstridende tekst. Oppgi den gjeldende prosessen først. Forklar deretter når den gjelder, hva kunden skal gjøre videre, og når en person må hjelpe til.

I det illustrerende eksempelet med returskjemaet bør svaret forklare hvor nye forespørsler starter, og hva som skjer med forespørsler som allerede behandles. Hvis den policyansvarlige ikke har avgjort hvordan utestående forespørsler skal håndteres, må ikke den som skriver, finne på en overgangsregel. La dette forbli en menneskelig vurdering til beslutningen foreligger.

Be en gjennomgåer som ikke skrev revisjonen, sammenligne den med endringsloggen. Be dem kontrollere målet, hvem som er kvalifisert, ikrafttredelsesdatoen, unntakene og neste trinn. En gjennomgang som bare vurderer tonen, vil ikke avdekke en manglende betingelse.

Kontroller et lite utvalg spørsmål før lansering

Oppbevar et gjenbrukbart spørsmålssett sammen med endringsloggen. For denne oppdateringen skriver du ned forventet svar eller forventet overføring til en person for hvert spørsmål før du gjennomgår et generert svar. Da har du et fastere grunnlag enn bare hvorvidt formuleringen ser bra ut.

• Det direkte spørsmålet: hvordan bruker kunden den nye prosessen?
• Det utdaterte spørsmålet: hva skjer når noen ber om den gamle prosessen ved navn?
• Overgangsspørsmålet: hva skal en person med en eksisterende forespørsel gjøre?
• Spørsmålet om manglende detaljer: hva skal skje når det er uklart om kunden er kvalifisert?
• Unntaksspørsmålet: hvilken situasjon krever en menneskelig beslutning?
• Det urelaterte spørsmålet: fungerer et svar utenfor endringen fortsatt som forventet?

Bruk et testmiljø eller en annen støttet gjennomgangsmetode som ikke sender eksperimentelle svar til kunder. Kontroller hver svarbane dere faktisk bruker. Et korrekt gjennomgått utkast bekrefter ikke at en separat bane for automatiske svar bruker de samme kildene.

Registrer spørsmålet, forventet resultat, observert svar, eventuelle kjente kildeproblemer og gjennomgåerens beslutning. Hvis svaret fortsatt inneholder den gamle instruksjonen, åpner du kildeoversikten på nytt. Hvis den underliggende regelen fortsatt er uklar, sender du saken tilbake til den policyansvarlige i stedet for å forsøke å reparere uklarheten gjennom gjentatte endringer i formuleringen.

Gjør lanseringsbeslutningen tydelig

Før du lanserer revidert innhold, bør du kreve at en navngitt gjennomgåer bekrefter at policyen er avklart, at de berørte kildene er kontrollert, og at spørsmålssettet gir akseptable resultater. La uavklarte temaer fortsatt være under menneskelig gjennomgang ved hjelp av kontroller som programvaren faktisk støtter. I Deskhero slås automatiske svar på per gruppe og chatboten på per widget. Den enkleste måten å holde ett tema tilbake på er derfor å la FAQ-svaret være ugodkjent til beslutningen foreligger.

Registrer når oppdateringen ble godkjent, og hvilke svarbaner som ble kontrollert. Ikke anta at publisering av en kilde beviser at alle svarbaner har tatt den i bruk. Kontroller funksjonen etter endringen, og se i verktøyets dokumenterte oppdateringsprosess hvis gammelt innhold fortsatt vises.

Gi brukerne en kort operasjonell merknad: hva som er endret, hvilken formulering som ikke lenger skal brukes, hvilke unntak som fortsatt er uavklarte, og hvem som eier disse unntakene. Merknaden bør hjelpe noen med å svare på neste sak uten å lese hele revisjonshistorikken.

Avslutt oppdateringen med en gjennomgang av virkelige samtaler

Etter lansering bør du undersøke et utvalg samtaler om det endrede temaet. Se etter gamle mål, motstridende kvalifiseringsregler, manglende neste trinn og kunder som måtte spørre på nytt. Ta med både tilsynelatende vellykkede svar og samtaler som ble overført til en person.

Spor korrigeringer etter årsak. En utdatert kilde krever kildevedlikehold. En uklar policy krever en policybeslutning. Et korrekt svar som kundene misforstår, krever tydeligere formulering. Ved å holde disse kategoriene atskilt unngår du å skrive om en FAQ for å løse et eierproblem.

Lukk endringsloggen når eieren har gjennomgått de observerte resultatene og tildelt eventuelt gjenstående arbeid. Ta vare på spørsmålssettet til neste revisjon. Målet er en gjentakbar vedlikeholdsvane: én ansvarlig eier, en sporbar policybeslutning, konsekvent kildemateriale og en kontrollert vei fra kundens spørsmål til det gjeldende svaret.