Så bygger du en kunskapsbas: artiklar, sök, behörigheter och AI-svar

En kunskapsbas är ett sökbart bibliotek med svar: hur man gör något, hur man åtgärdar något, vilken regel som gäller. För att bygga en behöver du artiklar grupperade i några tydliga kategorier, en redigerare som dina skribenter faktiskt använder, sök som hittar rätt artikel utifrån de ord människor verkligen skriver, och ett beslut om vem som får läsa vad: allmänheten, kunder som är inloggade eller bara personal. En AI-appbyggare kan ta fram strukturen, redigeraren och sökningen på en kort session. Det som gör en kunskapsbas användbar är skrivandet och underhållet, så designa för enkel redigering och för att upptäcka inaktuella artiklar redan från dag ett.

Bestäm först vem den är till för

Samma funktioner passar mycket olika webbplatser:

• Offentligt hjälpcenter: för kunder och potentiella kunder. Måste vara snabbt, indexerbart av sökmotorer och skrivet med deras egna ord.
• Dokumentation enbart för kunder: bakom en inloggning, för betalande kunder eller partners.
• Intern kunskapsbas: policyer, processer och instruktioner för personal. Måste vara privat. Sök och aktualitet är viktigare än design.

Att blanda offentliga och interna artiklar på en och samma webbplats är där de flesta läckor uppstår. Om du behöver båda, ge varje artikel en tydlig synlighetsinställning, eller kör två separata webbplatser.

Vad appen behöver

Data

Två fält gör mycket av jobbet: ägare (vem som ser till att artikeln stämmer) och senast granskad (när någon senast bekräftade att den fortfarande är sann). Tillsammans gör de det möjligt att lista artiklar som ingen har kontrollerat på sex månader.

Sidor

• Läsare: startsida med sök och kategorier, kategorisidor, artikelsidor med innehållsförteckning, relaterade artiklar och en fråga “Var detta till hjälp?”
• Redaktör: artikellista med filter (utkast, inaktuella, lågt betygsatta), en redigerare med förhandsvisning och versionshistorik.
• Admin: kategorier, användare och roller, samt rapporter över sökningar utan träffar.

Behörigheter

Läsare ser publicerade artiklar som de har tillgång till. Redaktörer skapar och redigerar artiklar, eventuellt begränsat till vissa kategorier. Admin publicerar, arkiverar och hanterar användare. För en intern kunskapsbas behöver alla inloggning. För ett offentligt hjälpcenter behöver bara skribenterna det.

Beslut och avvägningar

Redigerare: Markdown eller rik text

Markdown är snabbt, portabelt och fungerar bra med versionshistorik, men vissa skribenter tycker att det är avskräckande. En redigerare för rik text med rubriker, listor, bilder, noteringsrutor och kodblock känns bekant. Oavsett vilket du väljer, lagra innehållet i ett format du kan exportera senare.

Sök

Enkel textsökning i databasen räcker för några hundra artiklar om du söker i titlar, sammanfattningar och brödtext och rankar titelträffar högre. Utöver det, eller om stavfel och synonymer spelar roll (”faktura” kontra ”räkning”), använd riktig fulltextsökning eller en tjänst för sökning i molnet. Vår guide om att lägga till sök går igenom alternativen. Logga varje sökning som inte ger några träffar: det är en gratis lista över artiklar du behöver skriva.

AI-svar

En ruta för “ställ en fråga” som svarar utifrån dina artiklar är numera vanligt. Den fungerar genom att hämta de mest relevanta styckena och be en språkmodell att svara enbart utifrån dem. Se vad RAG är. Visa alltid källartiklarna, tillåt “jag vet inte”, och kom ihåg att den med stor säkerhet kommer att upprepa allt som är föråldrat i dina artiklar. Bygg den när artiklarna är i gott skick, inte innan.

Versionering och granskning

Behåll versioner så att du kan se vem som ändrade vad och kan återställa. För reglerat innehåll (HR-policyer, säkerhetsrutiner) lägger du till ett godkännandesteg innan en ändring publiceras.

Ett första prompt som fungerar

Bygg ett offentligt hjälpcenter för Parcelly, en app för fraktetiketter för småa nätbutiker. Startsidan har en stor sökruta och sex kategorier (Komma igång, Skriva ut etiketter, Transportörer, Fakturering, Returer, Felsökning). Artiklar har en titel, sammanfattning, brödtext i Markdown med bilder och noteringsrutor, kategori, taggar, status (utkast, publicerad, arkiverad), ägare och datum för senaste granskning. Artikelsidor visar en innehållsförteckning, relaterade artiklar och en fråga “Var detta till hjälp?” med ja/nej och en valfri kommentar. Sök täcker titlar, sammanfattningar och brödtext, med titelträffar rankade först, och loggar varje sökning och om den gav träffar. Ett redaktionsområde (kräver inloggning, roller redaktör och admin) listar utkast, artiklar som inte granskats på 180 dagar och artiklar med låga hjälpsamhetsbetyg, och sparar versionshistorik. Varje artikel har en egen sidtitel och metabeskrivning för sökmotorer. Ren, lugn och läsbar design. Mobil först.

Byggsteg

1. Lista de första 20–30 artiklarna utifrån verkliga supportfrågor innan du bygger något. Listan styr kategorierna.
2. Generera webbplatsen och kontrollera läsbarheten i telefon: radlängd, rubriker, bilder.
3. Redaktör och roller. Skribenter behöver kunna lägga till och rätta artiklar utan att be en utvecklare om hjälp.
4. Sök, och testa sedan med de ord kunderna faktiskt använder, även med stavfel.
5. Feedback och loggning av sökningar.
6. Rapport över inaktuella artiklar baserat på ägare och datum för senaste granskning.
7. SEO-grunder för en publik webbplats: unika titlar, beskrivningar, rena URL:er, en sitemap. Se SEO för AI-byggda webbplatser.
8. Länka den från din produkt och dina supportsvar, och följ loggen över sökningar utan träffar varje vecka.
9. AI-svar, när innehållet är gediget.

Vanliga misstag

• Att organisera efter avdelning i stället för efter vad läsaren försöker göra.
• Långa artiklar som täcker fem uppgifter. En uppgift per artikel, med en titel som säger vilket problem den löser.
• Ingen ägare per artikel. Ingen uppdaterar något, och förtroendet sjunker efter det första felaktiga svaret.
• Interna anteckningar i offentliga artiklar. Använd separat synlighet och granska innan publicering.
• Sök som bara matchar titlar. Läsare skriver symptom, inte artikelnamn.
• Skärmbilder utan alternativtext eller sammanhang. De blir snabbt föråldrade. Beskriv steget i ord också.

När en färdig produkt är det bättre valet

Om ditt team redan arbetar i ett verktyg för dokumentation eller wiki är en intern kunskapsbas där oftast den enklaste vägen. Vår jämförelse mellan Notion och Confluence täcker två vanliga val. Om du använder ett helpdesk-system kopplar dess inbyggda hjälpcenter artiklar till ärenden och föreslår artiklar för kunder, vilket är svårt att återskapa. Generatorer för dokumentationssajter är idealiska för utvecklardokumentation som ligger bredvid koden.

Bygg själv när du behöver en egen struktur eller egna behörigheter (artiklar per kund, per plats eller per roll), vill ha kunskapsbasen inne i din produkt i stället för på en separat sajt, behöver granskning och godkännande som en wiki inte tvingar fram, eller vill ha AI-svar över ditt innehåll utan ytterligare en prenumeration. Det passar naturligt ihop med ett eget helpdesk.

Så bygger du den med Mythex

På Mythex beskriver du kunskapsbasen i chatten, och den byggs i en live-förhandsvisning. Artiklar, versioner och feedback lagras i en Postgres-databas som agenten lägger till vid behov, och bilder hamnar i projektets fillagring. Inloggning för redaktörer använder en autentiseringslösning du väljer, eftersom Mythex inte har någon inbyggd inloggning för slutanvändare. För AI-svar använder du din egen AI-leverantörs API-nyckel, lagrad som projekthemlighet, och användningen debiteras på ditt konto hos leverantören och inte i Mythex-krediter (AI-receptet). Nya Mythex-appar är som standard en klientrenderad React-enkelsidesapp, vilket är svagare för sökmotorer. För ett offentligt hjälpcenter bör du därför be om en statisk eller serverrenderad uppsättning, till exempel Next.js (SEO-receptet).

Som startprompt kan du prova mallarna kunskapshubb för produkten eller teamdokumentationsapp.

Frågor