De fleste supportartikler fejler af én grund: de er skrevet til den person, der skrev dem, ikke den person, der har brug for dem.
Jeg ser det i næsten alle knowledge bases, jeg går ind i. Lange introduktioner. Screenshots af hver menu. Perfekt grammatik, der beskriver et problem med ord, ingen kunde nogensinde har skrevet. Og en søgebar, der ikke returnerer noget nyttigt.
Knowledge-Centered Success (KCS) vender spørgsmålet om. Den spørger ikke “Er denne artikel perfekt?” Den spørger to ting:
- Kan den næste person finde den?
- Kan de bruge den til at løse deres problem?
Det er hele barren. Findbar og brugbar. Alt nedenfor er, hvordan du kommer derhen.
1. Skriv den med kundens ord
Din kunde siger ikke “SSO token validation failure.” De siger “Jeg kan ikke logge ind, og den bliver ved med at sende mig tilbage til startsiden.”
Gæt hvilken af dem de skriver i søgebaren.
KCS kalder det at capture requesterens kontekst. Du registrerer problemet, som personen oplevede det: deres symptomer, deres fejlmeddelelse kopieret præcist, deres formulering. Ikke din diagnose. Ikke dit interne produktnavn.
Det er den største enkeltstående driver for findbarhed. Hvis artiklen ikke indeholder de ord, folk søger med, så findes den ikke. Uanset hvor god den er.
Prøv dette: åbn dine sidste ti artikler. Tæl hvor mange titler en kunde faktisk ville skrive. Vær ærlig.
2. Brug en simpel, konsistent struktur
En KCS-artikel er ikke et essay. Den er en lille, forudsigelig form:
De fire sektioner i en KCS-artikel: Issue, Environment, Resolution og Cause (valgfri), og hvad der hører til i hver.
Issue: Det personen ser eller ønsker, med deres ord. Eksempel: “Outlook bliver ved med at spørge efter min adgangskode efter opdateringen”
Environment: Hvad der er i spil: produkt, version, OS, setup. Eksempel: Outlook for Windows, Microsoft 365, version 2409
Resolution: Trinene der fikser det eller besvarer det. Eksempel: 1. Luk Outlook. 2. Ryd cachede legitimationsoplysninger. 3. Genstart og log ind.
Cause: Hvorfor det skete, hvis det er kendt. Eksempel: Forældede legitimationsoplysninger gemt før opdateringen
Hvorfor betyder det noget? Fordi når hver artikel ser ens ud, stopper folk med at læse og begynder at scanne. De hopper direkte til Resolution. De tjekker Environment for at se, om den matcher deres. Færdig.
Hold hver sektion stram. Korte sætninger. Nummererede trin. Én handling pr. trin. Hvis et trin kræver et afsnit for at forklare, er det nok to trin.
Og Cause er valgfri. Hold ikke en artikel tilbage, fordi du ikke ved hvorfor endnu. Fixet er det, folk har brug for i dag.
3. Skriv en titel, folk faktisk vil klikke på
Hvis du fulgte den rækkefølge, jeg foreslog, så er det nu, du skal tænke på titlen (og ikke det første, du skal skrive, når du starter en artikel), og det vil komme meget lettere til dig, når du først har skrevet indholdet i din artikel. Titlen gør det meste af arbejdet, når det kommer til findbarhed. I en liste med søgeresultater er det ofte det eneste, nogen læser, før de beslutter sig for at klikke eller gå videre.
En god KCS-titel er som regel bare Issue, med kundens ord. Ikke en kategori. Ikke et resumé af fixet. Problemet, som personen ville beskrive det.
- Start med symptomet, ikke løsningen. Folk søger efter det, der er galt, ikke efter svaret, de ikke kender endnu.
- Vær specifik. Nævn produktet, handlingen og hvad der går galt. “Login issue” matcher alt og hjælper ingen.
- Brug deres ord, ikke dine. Spring interne koder, teamnavne og akronymer over, som kunder aldrig ser.
- Inkludér den præcise fejlmeddelelse når der er en. Det er den mest søgte tekst, der findes.
- Sæt de vigtige ord først. Søgeresultater og mobilskærme afkorter titler.
Et par eksempler:
I stedet for: Adgangskodeproblem Prøv: Outlook bliver ved med at spørge efter min adgangskode efter opdateringen
I stedet for: VPN troubleshooting guide Prøv: VPN afbryder hvert par minutter, når jeg arbejder hjemmefra
I stedet for: Sådan fikser du print Prøv: “Printer offline”-fejl når jeg printer fra Teams
I stedet for: SSO token validation failure Prøv: Kan ikke logge ind, bliver ved med at sende mig tilbage til startsiden
Hurtig test: læs din titel højt. Hvis det lyder som noget, en frustreret person ville sige til en kollega, så er du på rette spor.
4. Gå efter tilstrækkeligt, ikke komplet
Det er den her, der gør perfektionister utilpasse.
I KCS behøver en artikel kun at være god nok til at hjælpe den næste person, der finder den. Ikke poleret. Ikke udtømmende. Tilstrækkelig til at løse.
Omkostningen ved at vente på perfekt er enorm. Mens én artikel ligger i en review-kø i tre uger, løser ti andre agenter det samme issue fra bunden. Ti kunder venter længere, end de behøvede.
En rå, præcis artikel publiceret i dag slår en smuk én publiceret næste måned. Hver gang.
Det betyder ikke, at alt går. Din organisation har stadig brug for en content standard: en kort, aftalt definition af, hvordan “godt nok” ser ud. Titelformat, obligatoriske felter, tone, hvad der aldrig kommer i en artikel. Hold det til en side eller to. Hvis ingen læser den, er det ikke en standard.
5. Capture det, mens du løser det, ikke efter
Her er den beskidte hemmelighed ved de fleste knowledge bases: artikler bliver skrevet sidst på dagen, fra hukommelsen, af en, der er træt.
Detaljerne er væk. Kundens præcise fejlmeddelelse er væk. Det du prøvede, som ikke virkede, er væk.
KCS beder dig om at capture undervejs. Start artiklen (eller opdatér en eksisterende), mens du arbejder på issuet. Indsæt kundens ord. Tilføj trin, mens du tester dem. Når ticketen er lukket, er artiklen stort set skrevet.
Det betyder også, at du søger først. Før du starter fra bunden, så søg i knowledge basen med kundens ord. Hvis noget allerede er der, så genbrug det. Hvis det er tæt på, så forbedr det. Opret kun nyt, når intet passer.
Intet ekstra projekt. Ingen “documentation week.” Bare en del af, hvordan arbejdet bliver gjort.
6. Lad brug forbedre det: genbrug er review
En god artikel er ikke færdig, når den er publiceret. Det er der, den begynder at blive bedre.
I KCS bliver en artikel reviewet hver gang nogen bruger den. Virker den stadig? Mangler der et trin? Er titlen klar? Hvis de kan fikse den, så fikser de den. Hvis de ikke kan, så flagger de den til en, der kan. Flag den eller fix den.
Det er derfor, du ikke har brug for et stort redaktionelt team, der signerer alt af på forhånd. De artikler, folk bruger mest, bliver reviewet mest. Dem, ingen rører, behøver alligevel ikke meget opmærksomhed.
Det virker kun med ét mindset-skift: ingen ejer en artikel. Teamet ejer knowledge.
Når jeg træner folk i KCS, kan jeg godt lide at bruge et simpelt ordsprog: see something, do something.
Tænk på skrald på kontorgulvet. Du kan træde over det, ignorere det og så klage over, at stedet er beskidt. Men så er du en del af problemet. Knowledge fungerer på samme måde. Ser du et forældet trin, en forvirrende titel eller en manglende fejlmeddelelse? Fix det eller flag det. Gå ikke forbi det.
7. Hvor AI passer ind (og hvorfor det betyder mere nu, ikke mindre)
Hver supportleder, jeg taler med, stiller det samme spørgsmål: kan AI ikke bare skrive artiklerne for os?
Delvist, ja. Og det er gode nyheder. Men kun hvis fundamentet er rigtigt.
AI som drafting partner. Ticketen indeholder allerede kundens ord, environment-detaljerne og de trin, agenten prøvede. AI kan omsætte den samtale til et første udkast i Issue / Environment / Resolution / Cause-format på få sekunder. Agentens job skifter fra at skrive til at validere: Er det korrekt? Er det med kundens ord? Ville det faktisk virke? Det er capture i workflowet, med langt mindre tastning.
Men læg mærke til, hvad AI draft’er ind i: din struktur og din content standard. Uden dem får du bare hurtigere inkonsistens.
AI som analyst. Det er den del, folk undervurderer. Når hver artikel følger den samme struktur og er linket til de tickets, den løste, har du pludselig rene, sammenlignelige data. AI kan spotte, hvilke issues der er stigende, hvilke produkter eller versioner der bliver ved med at dukke op i Environment, og hvilke Causes der peger på et fix, dit product team bør lave. Det er sådan, support stopper med bare at reagere og begynder at forebygge.
Rode, inkonsistente artikler giver AI intet at arbejde med. Strukturerede giver den et mønster at finde.
AI som hoveddøren. Flere og flere kunder vil aldrig se din artikel. De vil se et svar genereret ud fra den, af en chatbot eller en self-service assistant. Hvis artiklen er vag, forældet eller skrevet i intern jargon, vil AI-svaret også være det. Bare leveret mere selvsikkert.
Så nej, AI gør ikke gode artikler mindre vigtige. Den gør dem til fundamentet, alt andet står på. Og et menneske har stadig det endelige ansvar for, om knowledge er korrekt.
En hurtig tjekliste, før du trykker publicér
- Søgte jeg først, og genbrugte eller opdaterede i stedet for at duplikere?
- Er titlen skrevet på den måde, en kunde ville beskrive problemet?
- Indeholder Issue den præcise fejlmeddelelse eller symptom?
- Er Environment specifik nok til, at kunden kan se, om den gælder for dem?
- Er Resolution-trinene nummererede, én handling hver?
- Kan kunden, eller en helt ny agent, følge den uden hjælp?
- Er den korrekt? (Ikke perfekt. Korrekt.)
Den rigtige test
En god supportartikel måles ikke på, hvordan den læses. Den måles på, hvad der sker bagefter: kunden der fikser det selv, den nyansatte der lukkede en ticket på dag tre, eskaleringen der aldrig skete.
Mit job som konsulent er at gøre andre mennesker til eksperterne. Gode artikler gør det samme, i skala.
Hvis dit team bliver ved med at løse de samme problemer igen og igen, eller din knowledge base er fuld af artikler, ingen kan finde, så lad os tage en snak. Det er præcis det problem, KCS blev bygget til at fikse, og jeg kan hjælpe dig med at implementere det og adoptere det, så det hænger ved 🙂