MuninMunin
Logg innKom i gang gratis
Home/Journal/Kunnskapsbasen din bør skrive seg selv.
Field note · 7 min read

Kunnskapsbasen din bør skrive seg selv.

Noen på teamet ditt har allerede skrevet svaret. Det gikk til én person og ble liggende i én tråd. Her er kureringsrunden som gjør hver løste overlevering til en gjennomgått kunnskapsartikkel — arkivert i løpet av sekunder, kun synlig for administratorer til et menneske løfter den.

A small cobalt blue painted post box with its flap closed, mounted on a weathered fence post beside a gravel track along a Norwegian shoreline.
Lagt i kassa én gang, ved stien den neste går.

Sist tirsdag skrev noen på teamet ditt et godt svar. Tre setninger, ti minutter på å få riktig, levert til nøyaktig én person. Det ligger fortsatt i den tråden. Neste måned kommer det samme spørsmålet fra noen andre, og den som tar det, vil enten grave etter den tråden eller skrive svaret på nytt fra bunnen. De fleste supportteam betaler for det samme svaret fire eller fem ganger før noen kommer på å skrive det ned.

Hvorfor kommer det samme spørsmålet igjen og igjen?

Fordi svaret ble levert, ikke nedtegnet. Et supportsvar er adressert til én person og arkivert i én samtale, så kunnskapen i det blir aldri søkbar for den neste som trenger den. Hver gjentakelse etter den første er et dokumentasjonshull som betales i arbeidstid, én tråd om gangen.

Grunnen til at ingen fikser det, er at å skrive det ned er en egen arbeidshandling, gjort på det dårligst tenkelige tidspunktet. Tråden er lukket, kunden er fornøyd, den neste venter. Dokumentasjon taper den konkurransen hver eneste dag, og den taper mot noe helt rimelig.

Kan AI gjøre supportsaker om til kunnskapsartikler?

Ja, og tre leverandører gjør det i produksjon. Zendesks Knowledge Builder grupperer historiske saker i intensjoner og skriver et utkast til en artikkel for hver av dem med høyt volum. Intercom løfter fram innholdsanbefalinger fra samtaler Fin måtte eskalere. Munin arkiverer én kandidat per besvart spørsmål i en innboks bare administratorer ser. Alle tre holder et menneske mellom utkastet og kunden, og det er den eneste delen som ikke er valgfri.

Hva Munin gjør i det øyeblikket et menneske svarer

Utløseren er presis, og det betyr noe at den er det. Når en selvbetjeningsagent ikke kan svare fra kunnskapsbasen, kaller den conv_request_handover — den stopper og ber om en person framfor å lage noe plausibelt. Et menneske svarer. Overleveringen løses, og handoverResolvedAt stemples på samtalen.

Det stempelet er signalet. Det merker det nøyaktige settet av samtaler der et spørsmål løp fra kunnskapsbasen og en person tettet hullet for hånd — som er nettopp den populasjonen en kunnskapsartikkel bør skrives fra. Ikke alle saker. Ikke de populære. De som beviste at dokumentasjonen manglet.

Munin kjører kureringsrunden i to modi ut fra det signalet. En sidevogn fyrer på hver conversation.handover_resolved-hendelse, så kandidaten finnes innen sekunder etter at svaret gikk ut. Et ukentlig batch-sveip leser de siste sju dagene på nytt som sikkerhetsnett, i tilfelle sidevogna var nede. Begge kjører de samme fem stegene.

  • 01Sjekk hva som allerede er vurdert. kb_list_curation_decisions returnerer én rad per tidligere beslutning, med avvisningsgrunnen. De kildesamtalene droppes før skrivingen starter — en operatørs nei utløper ikke.
  • 02Finn hullene. conv_list_conversations med handover: "resolved" og et since-vindu. Serveren anvender filteret, så radene som kommer tilbake er allerede det aktuelle settet.
  • 03Les paret. conv_get_conversation returnerer hele messages[]-arrayet. Sluttbrukerens spørsmål, agentens overlevering, så den siste klyngen med menneskelige svar — den klyngen er det kanoniske svaret.
  • 04Sjekk at det ikke allerede er dekket. kb_search på kjernen i spørsmålet. Svarer et dokument avgrenset til self_service-publikumet allerede på det, var hullet oppdagbarhet, ikke dekning, og ingen kandidat arkiveres.
  • 05Arkiver utkastet. kb_propose_curation_candidate skriver et FAQ-formet utkast på 100–300 ord inn i kb-curation-inbox-rommet, merket curation og candidate, med publikum admin alene.
jsoncén kandidat, arkivert for gjennomgang
{
  "name": "kb_propose_curation_candidate",
  "arguments": {
    "subject": "Åpningstider i helgen",
    "draftBody": "Vi har åpent **10–16 på lørdager** og 12–16 på søndager. Filialen i sentrum holder hverdagsåpent alle dager.",
    "sourceConversationId": "ccv_…",
    "proposedTargetSpaceSlug": "support-faq"
  }
}

Hvorfor går ikke utkastet rett til kundene?

Fordi et publikum er et felt, ikke et håp. Kandidaten opprettes med publikum admin, i et rom sluttbrukeragenter ikke kan lese. Kundene dine blir fortsatt overlevert til et menneske på det spørsmålet til noen løfter utkastet — som er riktig feilmodus, fordi alternativet er å publisere et ulest LLM-utkast til dem som betaler deg.

Løftingen skjer i dashbordets kureringsinnboks, der et menneske løfter den: dokumentet flyttes inn i målrommet, kandidatmerkene faller bort, og publikumene settes — med ['admin', 'self_service'] som standard, så selvbetjeningsagenten finner det neste gang. Avvisning er kb_dismiss_curation_candidate med en grunn, som sletter utkastet og registrerer beslutningen, så ingen senere runde stille kan arkivere den samme samtalen på nytt.

Publisering er bundet til teksten som ble gjennomgått

Løfting fra kureringsinnboksen er bundet til en ifVersion — kandidatens versjon slik den som gjennomgikk den leste den. Har utkastet flyttet seg i mellomtiden, fra din egen redigering eller noen andres, feiler løftingen med kb_version_conflict, og ingenting skrives til målrommet.

Fristelsen er å lese dokumentet på nytt og prøve igjen med den nye versjonen. Ikke gjør det. Da publiserer du tekst den som gjennomgikk aldri så. Les den på nytt, vis dem den gjeldende teksten, og få deres ord på akkurat den. Den samme avvisningen beskytter en foreldet Slack-knapp eller et kort i et panel som ble tegnet før redigeringen.

Et utkast ingen leste er ikke dokumentasjon. Det er en hallusinasjon med en URL og logoen din på.

Hva nekter runden å skrive ned?

Fire ting, og disiplinen er mesteparten av verdien. En kunnskapsbase fylles med støy fortere enn den fylles med kunnskap, og når den først gjør det, blir hver agent som leser fra den dårligere.

Ettordssvar. «Ja.» «Selvsagt.» Det er ingen artikkel i det.

Kundespesifikk tilstand. Kontoen din er sperret fordi vi flagget en tilbakeføring forrige uke er sant om én person og hører ikke hjemme i nærheten av et dokument hele kundebasen din kan søke i. Navn, e-poster, kontonumre og interne saksreferanser strippes når utkastet skrives.

Alt som allerede er dekket. Det er steg 04. Et duplikatdokument er verre enn intet dokument, fordi hybrid gjenfinning — fulltekst pluss embeddinger — nå har to kandidater å være uenige om.

Driftsstatus. «Vi er nede for vedlikehold til kl. 15» er en statusside, ikke kunnskap.

Én til, på grensen: kom begge halvdeler av paret fra agenter — selvbetjeningsagenten og en admin-agent som snakker med hverandre — arkiveres ingenting. Intet menneske bekreftet det svaret, så det er ingenting å løfte.

Hvordan skiller dette seg fra Zendesk Knowledge Builder eller Intercoms anbefalinger?

De tre produktene løser det samme problemet fra tre ulike ender, og forskjellene er reelle framfor markedsføring.

  • Zendesk Knowledge BuilderEtterfylling i volum. Den leser historiske saker, grupperer dem i intensjoner, og skriver utkast til en artikkel for hver av dem med høyt volum, så et hjelpesenter kan finnes der det ikke fantes ett. Generelt tilgjengelig for kunder med Knowledge-produktet; de generative redigeringsfunksjonene i Knowledge krever tillegget Advanced AI. Bruk av AI-agenten faktureres per automatiserte løsning, finansiert av en løsningskvote, med satsen oppgitt av selger framfor publisert.
  • Intercoms innholdsanbefalingerHulldeteksjon på det du allerede publiserer. Fin løfter fram forslag til nye artikler og utdrag fra samtaler den måtte eskalere, og flagger duplikater og motsigelser i eksisterende innhold. Intercom foreslår en ukentlig gjennomgangsrunde. Fin selv faktureres til 0,99 dollar per Fin-utfall oppe på minst ett sete.
  • Munins kureringsrundeHendelsesformet, én samtale om gangen. En løst overlevering gir en kandidat innen sekunder, i et rom bare administratorer ser, skrevet av hvilken modell du enn peker mot verktøyene. Prosedyren er markdown du kan lese og redigere før du stoler på den, og hele plattformen er MIT-lisensiert.

Hvilken bør du bruke?

Kjører du allerede Zendesk og sitter på to år med saker du gjerne vil ha gjort om til et hjelpesenter innen fredag, bruk Knowledge Builder. Etterfylling av historikk i bulk gruppert etter intensjonsvolum er nettopp den jobben den ble bygd for, og Munins runde er formet annerledes: den er hendelsesdrevet, én løst overlevering om gangen, og den begynner å produsere fra den dagen du slår den på framfor fra arkivet ditt. Vil teamet ditt ha en tiårsdyp redaksjons- og rapporteringspakke rundt kunnskap, har Zendesk og Intercom begge en.

Velg Munin når flaskehalsen ligger et annet sted — og for mange team gjør den det.

Svaret og kundeposten ligger i den samme databasen. Et kurert dokument, samtalen det kom fra, og kontakten som spurte, bor alle i ett Postgres-skjema med én contacts-tabell, så runden leser en tråd og skriver et dokument uten en integrasjon imellom. Ingenting synkroniseres, fordi ingenting er atskilt.

Runden kjører der du allerede jobber. Det er MCP-verktøy og en markdown-prosedyre, ikke en funksjon inne i et UI du må logge inn i — så den kjører fra Claude Code, Cursor, ChatGPT, OpenAI Agents SDK, eller en kjører du skrev selv, mot de samme 200-og-noe verktøyene og den samme revisjonsloggen. Samme katalog, uansett hvem som ringer.

Du kan lese prosedyren før du stoler på den. Kureringsferdigheten er én av 60 medfølgende markdown-ferdigheter. Den forteller agenten hva den skal hoppe over, hvor langt et utkast bør være, og at den aldri skal løfte automatisk. Er den feil for teamet ditt, redigerer du markdownen, og oppførselen endrer seg ved neste kjøring — ingen sak, ingen veikart.

Og prismåleren er ikke festet til utfallet. Munin Cloud Free koster 0 € i måneden med 5 000 MCP-kall, 250 kontakter og 100 MB lagring — nok til å kjøre denne runden på en reell supportavdeling. Selvdrift er docker compose up under en MIT-lisens uten noen enterprise/-katalog som holder på den nyttige halvparten. AI-kostnaden er det modelleverandøren din tar, ikke et gebyr per løsning til oss. Det er det samme argumentet jeg førte om målere per sete og per løsning generelt, anvendt på den ene funksjonen der måleren ville bitt hardest.

1
kandidat per besvart spørsmål, arkivert for gjennomgang
100–300
ord i et kureringsutkast
admin
det eneste publikumet som ser den før du løfter den
0 €
for å kjøre runden på Munin Cloud Free

Hvordan ser det ut etter en måned?

En kort kø og en kunnskapsbase som vokste uten at noen satte av tid til å skrive den. Ti eller tolv kandidater i måneden er normalt for en liten supportavdeling. De fleste er to avsnitt, de fleste er riktige, og å jobbe seg gjennom dem tar en kaffe verdt oppmerksomhet: les, stram en setning, løft eller avvis med en grunn.

Det du faktisk merker, er av andre orden. Overleveringsvolumet på spørsmålene du allerede har svart på én gang begynner å falle, fordi selvbetjeningsagenten nå kan sitere et dokument i stedet for å hente et menneske. Runden er i praksis en tilbakekoblingssløyfe som nedbetaler nettopp den gjelda den oppdager — og den har samme form som å holde CRM-et à jour ut fra samtaler du allerede hadde. Les tråden du allerede har. Skriv posten ingen hadde tid til. Stopp før den ugjenkallelige biten og spør.

Det som er igjen på pulten din, er dømmekraften: er dette generelt nok til å publisere, er det formulert slik en kunde ville søkt etter det, motsier det noe vi allerede sier.

Ofte stilte spørsmål

Kan AI skrive kunnskapsartikler fra supportsakene mine? Ja. Munin skriver utkast til ett FAQ-formet dokument per besvart spørsmål — ett agenten ikke kunne svare på og et menneske så svarte på — og arkiverer det for gjennomgang. Zendesks Knowledge Builder gjør den samme jobben i bulk fra sakshistorikk, og Intercom anbefaler innhold fra samtaler Fin eskalerte. I alle tre er det en person som publiserer.

Kommer en AI-skrevet hjelpeartikkel ut uten at noen har lest den? Nei. I Munin opprettes kandidaten med publikum admin i et rom sluttbrukeragenter ikke kan lese, og bare et menneske som løfter den fra kureringsinnboksen flytter den til et kundevendt rom med self_service-publikum. Det finnes ingen konfidensterskel som hopper over mennesket.

Hva skjer hvis noen redigerer utkastet mens det venter på gjennomgang? Løftingen nekter. Den er bundet til ifVersion — versjonen den som gjennomgikk leste — og feiler med kb_version_conflict hvis teksten har flyttet seg, så ingenting når kundene som en person ikke godkjente i sin nåværende form.

Kan jeg importere hjelpesenteret jeg allerede har? Ja. Ferdigheten kb/import-articles-in-bulk laster eksisterende artikler fra CSV eller JSON, og det finnes ferdigheter for å dele opp lange dokumenter så hybrid gjenfinning yter godt. Kurering legger så til på det grunnlaget fra levende samtaler framfor å starte fra null.

Hvilken AI-modell skriver utkastene? Hvilken som helst av dem. Runden er en markdown-prosedyre pluss MCP-verktøy, så den kjører på Claude, ChatGPT, Gemini, Codex eller en modell du drifter selv — og modellen du velger er en konfigurasjonslinje, ikke en migrasjon.

Hva koster det å kjøre? Munin Cloud Free koster 0 € i måneden og inkluderer 5 000 MCP-kall, som dekker kureringen for en liten supportavdeling med god margin. Selvdrift under MIT er fri for lisenskostnad. Din eneste variable utgift er det modelleverandøren din tar for skrivingen.

Kortversjonen

  • Svaret finnes allerede — det ligger i en tråd. Kurering flytter det dit den neste kunden, og den neste agenten, kan finne det.
  • Utløseren er en løst overlevering: et spørsmål agenten ikke kunne svare på og et menneske så svarte på. Det settet er nøyaktig der dokumentasjonen mangler.
  • Én kandidat per besvart spørsmål, arkivert innen sekunder i et rom bare administratorer ser.
  • Publisering bindes med ifVersion til nøyaktig den teksten den som gjennomgikk leste, så en redigering i mellomtiden nekter framfor å sende ugjennomgått prosa til kunder.
  • Runden hopper over ettordssvar, privat kontotilstand, driftsmeldinger og alt kb_search viser allerede er dekket — og arkiverer aldri en samtale en operatør allerede har vurdert, på nytt.
  • Zendesk Knowledge Builder etterfyller fra sakshistorikk; Intercom flagger hull fra eskaleringer; Munins runde er hendelsesformet, MIT-lisensiert, og kjører på den MCP-klienten og modellen du allerede bruker.

Kureringsprosedyren er markdown du kan lese før du stoler på den — den ligger i dokumentasjonen, og Munin Cloud er gratis å kjøre en runde på.

Et svar som bor i én tråd er ikke kunnskap. Det er en tjeneste du gjorde én gang.

Kjell Rune Monsø, gründer.