AI-programvara för kundservice: Håll svaren aktuella

Din leveranspolicy ändras. Webbplatsen ger nu rätt svar, men en gammal FAQ-post och supportmeddelanden från förra månaden beskriver fortfarande den tidigare processen. Innan du låter AI-programvara för kundservice besvara nästa fråga behöver du veta vilka källor som har ändrats och vilka svar som fortfarande behöver granskas.

Den här guiden handlar om underhåll av kunskapsinnehåll efter lansering: hur du hanterar en policyändring, sammanför motstridiga svar och ger ditt team ett tydligt lanseringsbeslut. Det är en checklista för det löpande arbetet, inte en produktjämförelse. Om du fortfarande väljer programvara kan du börja med den praktiska utvärderingsguiden.

Börja med en ändringspost, inte med ett omskrivet svar

När en policyansvarig meddelar en ändring ska du dokumentera vad som har ändrats innan du redigerar supportinnehåll. Ett välformulerat svar är inte redo för kunderna om ingen har bekräftat när det gäller. Förvara posten i ert befintliga delade dokument eller i er uppgiftshanterare; det kräver inget nytt verktyg.

Dokumentera den policyansvariga, ikraftträdandedatumet, vilka kunder eller produkter som berörs, den tidigare regeln och ersättningsregeln. Lägg till eventuella undantag och personen som kan lösa dem. Länka posten till det auktoritativa policydokumentet så att en granskare kan kontrollera beslutet i stället för att förlita sig på ett vidarebefordrat meddelande.

Föreställ dig till exempel att ditt företag går från returförfrågningar via e-post till ett returformulär. Ange om pågående förfrågningar fortfarande ska hanteras via e-post och om formuläret gäller för alla produkter. Det här är exempel på frågor, inte en Deskhero-policy. Utan dessa uppgifter kan två olika svar låta rimliga samtidigt som de hänvisar samma kund till olika ställen.

Följ det ändrade svaret genom alla dess källor

Sök efter den gamla formuleringen, den gamla destinationen och vanliga omskrivningar. Titta längre än på sidan där ändringen meddelades. En kund kan fråga hur man påbörjar en retur, vart en returförfrågan ska skickas eller om en tidigare förfrågan fortfarande gäller. Behandla detta som en och samma kunskapsuppdatering med flera ingångar.

Skapa en kort källförteckning. För varje punkt dokumenterar du dess plats, avsedda målgrupp, ägare och åtgärd som krävs. Användbara åtgärder är bland annat att uppdatera instruktionen, ta bort en dubblett, märka en historisk hänvisning eller be den policyansvariga avgöra en konflikt.

• Offentliga FAQ-svar: kontrollera huvudsakliga svar och relaterade frågor som nämner samma process.
• Intern kunskap: uppdatera instruktioner för undantag och eskalering samt standardsvaret.
• Webbplatssidor: granska hjälpinnehåll och andra sidor som upprepar den gamla instruktionen.
• Svarsmallar: ersätt sparade formuleringar som ditt team fortfarande kan skicka manuellt.
• Historiska konversationer: identifiera gamla exempel som behöver extra granskning om de används när ett nytt utkast tas fram.

Skriv inte om historiska kundkonversationer för att få dem att se aktuella ut. Bevara dokumentationen över vad som hände. Dokumentera i stället den aktuella regeln tydligt och be granskare vara uppmärksamma på föråldrade instruktioner i nya svar. I Deskhero tas ett avvisat eller borttaget offentligt FAQ-svar bort från automatiska svar, medan tidigare ärenden fortfarande påverkar svarsutkast. Därför bör granskare vara uppmärksamma på föråldrade formuleringar i utkasten.

Separera offentliga svar från interna hanteringsinstruktioner

Skriv det kundvända svaret kring den åtgärd som kunden kan vidta. Lägg personalinterna undantag, godkännandesteg och utredningsanteckningar i interna instruktioner. Gör inte om en hel intern konversation till en offentlig FAQ bara för att den innehåller ett användbart svar.

Den här skillnaden är viktig i Deskhero eftersom den kunskap som är tillgänglig för granskade utkast skiljer sig från den kunskap som används för automatiska svar. Deskheros svarsutkast bygger på kunskap i arbetsytan, däribland FAQ-innehåll, intern kunskap, hämtade webbplatssidor och tidigare ärenden. Användare granskar och skickar dessa utkast. Dess chattbot och automatiska e-postsvar som aktiverats av användaren svarar endast utifrån den godkända offentliga FAQ:n, och du kan aktivera dem när 100 FAQ-svar har godkänts. Frågor som ligger utanför den kunskapen skickas till en person.

Använd den skillnaden för att definiera granskningsomfattningen: granska breda kunskapskällor med avseende på kvaliteten i utkasten och granska godkända offentliga svar med avseende på kundvänd automatisering. Översikten över Deskheros AI-programvara för kundservice förklarar hur dessa arbetsflöden hänger ihop om du behöver anpassa din underhållsprocess till produkten.

Skriv om svaret utan att dölja undantaget

För varje berörd FAQ-post tar du fram en komplett ersättning i stället för att lägga till en rättelse under motsägelsefull text. Ange den aktuella processen först. Förklara sedan när den gäller, vad kunden ska göra härnäst och när en person behöver hjälpa till.

I exemplet med returformuläret ska svaret förklara var nya förfrågningar börjar och vad som händer med förfrågningar som redan hanteras. Om den policyansvariga inte har beslutat hur pågående förfrågningar ska hanteras får skribenten inte hitta på en övergångsregel. Låt den delen hanteras av en människa tills beslutet finns.

Be en granskare som inte skrev ändringen att jämföra den med ändringsposten. Be granskaren kontrollera destination, behörighet, ikraftträdandedatum, undantag och nästa steg. En granskning som bara fokuserar på tonen upptäcker inte ett villkor som saknas.

Kontrollera ett mindre antal frågor före lansering

Förvara en återanvändbar uppsättning frågor bredvid ändringsposten. För den här uppdateringen skriver du ned det förväntade svaret eller den förväntade hänvisningen för varje fråga innan du granskar något genererat svar. Då har du något mer konkret att utgå från än om formuleringen ser bra ut.

• Den direkta frågan: hur använder kunden den nya processen?
• Den föråldrade frågan: vad händer när någon ber om den gamla processen med dess namn?
• Övergångsfrågan: vad ska någon med en befintlig förfrågan göra?
• Frågan om saknade detaljer: vad ska hända när det är oklart om kunden uppfyller kraven?
• Undantagsfrågan: vilket fall kräver ett mänskligt beslut?
• Den orelaterade frågan: fungerar ett svar utanför ändringen fortfarande som förväntat?

Använd en testmiljö eller en annan stödd granskningsmetod som inte skickar experimentella svar till kunder. Kontrollera varje svarsväg som ni faktiskt använder. Ett korrekt granskat utkast visar inte att en separat väg för automatiska svar använder samma källor.

Dokumentera frågan, förväntat resultat, observerat svar, eventuellt känt källproblem och granskarens beslut. Om svaret fortfarande innehåller den gamla instruktionen ska du öppna källförteckningen igen. Om den underliggande regeln fortfarande är tvetydig ska du återföra den till den policyansvariga i stället för att försöka reparera tvetydigheten genom upprepade ändringar av formuleringen.

Gör lanseringsbeslutet tydligt

Innan reviderat innehåll lanseras ska du kräva att en namngiven granskare bekräftar att policyn är fastställd, att de berörda källorna har kontrollerats och att frågeuppsättningen ger acceptabla resultat. Låt olösta ämnen fortsätta granskas av människor med hjälp av kontroller som programvaran faktiskt stöder. I Deskhero aktiveras automatiska svar per grupp och chattboten per widget, så det enklaste sättet att hålla tillbaka ett ämne är att låta dess FAQ-svar förbli ogodkänt tills beslutet finns.

Dokumentera när uppdateringen godkändes och vilka svarsvägar som kontrollerades. Utgå inte från att publicering av en källa bevisar att varje svarsväg har hämtat in den. Kontrollera beteendet efter ändringen och konsultera verktygets dokumenterade uppdateringsprocess om gammalt innehåll fortfarande visas.

Ge användarna en kort operativ anteckning: vad som ändrades, vilka formuleringar de ska sluta använda, vilka undantag som fortfarande är olösta och vem som ansvarar för dessa undantag. Anteckningen ska hjälpa någon att besvara nästa ärende utan att läsa hela ändringshistoriken.

Avsluta uppdateringen med en granskning av verkliga konversationer

Efter lanseringen granskar du ett urval av konversationer om det ändrade ämnet. Leta efter gamla destinationer, motstridiga regler för behörighet, saknade nästa steg och kunder som behövde fråga igen. Ta med både svar som verkar ha fungerat och konversationer som gick vidare till en person.

Följ upp rättelser utifrån orsak. En föråldrad källa kräver underhåll av källan. En otydlig policy kräver ett policybeslut. Ett korrekt svar som kunder missförstår behöver tydligare formuleringar. Om du håller dessa kategorier åtskilda undviker du att skriva om en FAQ för att lösa ett ägarproblem.

Stäng ändringsposten när ägaren har granskat de observerade resultaten och tilldelat eventuellt återstående arbete. Spara frågeuppsättningen till nästa revidering. Målet är en återkommande underhållsvana: en ansvarig ägare, ett spårbart policybeslut, konsekvent källmaterial och en kontrollerad väg från kundens fråga till det aktuella svaret.