Intern wiki: værktøjer, struktur og den wiki, der vokser ud af kanalens historik (2026)

En intern wiki er den samling sider, en organisation skriver til sig selv og ingen andre: hvordan en ny distributør oprettes, hvor den gældende prisliste ligger, hvad der blev besluttet om rabatter i juni, og hvem man ringer til, når speditøren er forsinket. Den er intern, fordi læseren er en kollega, og den er en wiki, fordi ethvert medlem kan skrive en side, og enhver side kan linke til en anden. En organisation med 10–200 medarbejdere har en wiki fra den dag, en anden person stiller det samme spørgsmål. Valget er kun, om siderne findes, eller om svaret bor i én kollegas hoved og et dusin chattråde.

De fleste guides til interne wikier er lister over software. Denne starter tidligere, fordi værktøjet er den mindste af beslutningerne: en wiki, der virker, er en struktur, folk kan navigere i, et sideformat, der holder sig sandt, og et sted, teamet allerede åbner hver dag. Først kommer håndværket: strukturen, en sideskabelon, du kan kopiere, og et eksempel fra en klinik. Derefter mekanikken: hvor wikien bor i de værktøjer, dit team allerede bruger, ifølge deres egen dokumentation, og hvad hvert af dem gør med det møde, hvor reglen faktisk blev fastlagt. For en wiki prøves ikke på lanceringsdagen. Den prøves den mandag, en ny kollega åbner den og finder siden på et sprog, vedkommende læser.

Hvad en intern wiki er – og hvad den ikke er

Fire ting bliver kaldt en wiki, og forvekslingen mellem dem er grunden til, at så mange bliver bygget og så få bliver åbnet:

Wikien er den første række, og det er den, de tre andre afhænger af. En vidensbase er en wiki med struktur håndhævet: ét indlæg pr. spørgsmål og en ejer på hvert. Metoden til at bygge en på 30 dage står i den guide, og denne handler om wikiens egen form. Intranettet er det, wikien bliver til, når kun tre personer må skrive. Det delte drev er der, hvor wikiens filer ligger, og wikiens opgave er at pege på den aktuelle. En wiki er heller ikke et procesdokument eller en SOP: de beskriver ét arbejdsgang fra ende til anden, mens en wikiside siger, hvor man finder dem, og hvad der har ændret sig siden.

Det, der gør en wiki intern, er ikke en adgangskode. Det er, at siderne er skrevet med de ord, teamet bruger – "Casablanca-reglen", "tirsdagsturen" – og at de kan sige det, en ekstern side aldrig kunne: hvem der besluttede, hvorfor, og hvad det afløste.

Strukturen: syv sektioner, én side pr. spørgsmål

Forskellen på en wiki, folk åbner, og en, de er holdt op med at åbne, er sjældent værktøjet. Det er tre beslutninger, der er truffet eller ikke truffet, før den første side skrives.

Sektioner efter spørgsmål, ikke efter afdeling. Kollegaen, der spørger "hvordan fakturerer vi en distributør i Schweiz?", ved ikke, om svaret hører under økonomi, salg eller logistik. Vedkommende kender spørgsmålet. En wiki organiseret efter afdeling sender dem gennem tre sektioner for at finde én side. Organisér efter de spørgsmål, folk stiller, med deres egne ord, og hold øverste niveau til syv sektioner eller færre. Ud over syv har selve strukturen brug for en søgning, og en søgning i en wiki, ingen har fyldt endnu, giver ingenting. Typiske topniveauer for en lille organisation: kunder og ordrer; penge og fakturering; mennesker og ansættelse; værktøjer og adgang; regler og beslutninger; hvem man ringer til.

Én side pr. spørgsmål, under en skærm. En side, der besvarer ét spørgsmål, bliver fundet og læst. En side, der forklarer en hel funktion, bliver bogmærket og skimmet. "Hvordan fakturerer vi Schweiz?" er en side. "Økonomi" er en sektion. Hvis en side har brug for en indholdsfortegnelse, er den to sider.

En ejer og en dato på hver side. En side, der siger, hvem der ejer den, og hvornår den sidst blev tjekket, bliver troet på. Den samme tekst uden dem er "nok forældet". Ejerens opgave er lille – en gang i kvartalet at svare på "er det her stadig rigtigt?" og ændre datoen – og det er det eneste, der holder en wiki i live ud over det første år. En side, ingen kan navngives for, er ikke viden. Det er et gæt, og den bliver fjernet.

To vaner bevarer strukturen, når den først findes. Hvert svar i teamets kanal, der bliver spurgt om to gange, bliver til en side, skrevet af den, der svarede, og linket fra den sektion, den hører til. Og hver beslutning, der ændrer en regel, får først sin linje i beslutningsloggen, og så linker den side, der angiver reglen, til den, så siden seks måneder senere kan sige ikke bare, hvad reglen er, men hvorfor.

Sådan opretter du en intern wiki på en uge

Planen forudsætter én person, der driver den – teamlederen eller den, der får flest spørgsmål – mens resten af teamet bruger få minutter.

Dag 1 – vælg stedet efter, hvor teamet allerede læser. Ikke efter en softwaresammenligning. Wikien bor, hvor spørgsmålene bliver stillet: teamets kanal, den pakke, filerne allerede ligger i. En wiki i et femte værktøj med sit eget login er en wiki, ingen åbner mandag morgen. Tabellen længere nede viser, hvad hvert sted rummer, og hvor hvert af dem stopper.

Dag 1–3 – indsaml spørgsmålene, ikke svarene. Skriv én besked i kanalen: "Svar med hvert spørgsmål, du stillede en kollega i denne uge, med de ord, du brugte." På dag tre er der fyrre til tres, og en tredjedel er dubletter. Tæl gentagelserne: spørgsmålet, der er stillet fem gange, er side ét.

Dag 4 – sortér i syv sektioner, navngiv ejerne. De grupper, spørgsmålene falder i, er sektionerne. Navngiv en ejer pr. sektion – den, der besvarede flest af dens spørgsmål – og en ejer for hver af de første femten sider. Skriv ikke andet endnu end listen: sektion, spørgsmål, ejer. Send den tilbage til teamet med ét spørgsmål: "hvad mangler?"

Dag 5–7 – de første femten sider, ud fra det, der allerede findes. Hver ejer skriver sine sider med skabelonen nedenfor og tager udgangspunkt i chatsvaret, recap'en fra mødet, hvor reglen blev fastlagt, og filen, der blev vedhæftet i marts. Reglen for den første uge er "kort og sandt slår langt og komplet": et svar på to sætninger med et link til filen, dateret og signeret, er en side. Fastgør derefter sektionsindekset, hvor teamet læser, og så findes wikien.

Det, der ikke sker i løbet af ugen: at flytte det delte drev, at skrive en side for hver proces, at vælge et nyt værktøj. Wikien peger på filer, hvor de ligger, og på procedurer, hvor de bor.

En skabelon til en side i den interne wiki

Én side, ét spørgsmål, under en skærm. Kopiér den som en note og udfyld den. De tre sidste linjer springes oftest over, og det er dem, der holder siden sand.

[Spørgsmålet, med de ord folk bruger, når de spørger]
Ejer: [navn] · Sektion: [en af de syv] · Sidst gennemgået: [dato] · Næste gennemgang: [dato]
Kort svar: [to sætninger – hvad man skal gøre]
Gælder for: [team, kontor, kundetype] · Gælder ikke for: [det tilfælde, folk forveksler det med]
Sådan: [nummererede trin, hvert med det system, den person eller den fil, det involverer]
Reglen bag: [den beslutning, der fastlagde den, med dato og begrundelse – link til beslutningsloggen]
Undtagelser: [tilfældene uden for den normale vej, og hvem der afgør hver enkelt]
Hvor filerne er: [link til den aktuelle skabelon, prisliste, kontrakt]
Relaterede sider: [SOP'en, processen, den forrige version af denne side]

Skabelonen er ren tekst med fede etiketter, så den kan indsættes i en Word-fil, et Google Doc, en wikiside, et Slack canvas eller en chatnote uden omformatering.

Et eksempel fra praksis: en kliniks wiki efter én uge

En fysioterapiklinik i Barcelona med 24 ansatte: en reception på fire, fjorten terapeuter, to i fakturering og resten administration. Halvdelen af terapeuterne er kommet fra Argentina, Colombia og Ukraine inden for de seneste to år, og en tredjedel af patienterne er britiske og tyske tilflyttere, der booker på engelsk. Tre dages indsamling gav 52 spørgsmål, efter fjernelse af dubletter 37. Den struktur, der kom ud af det, med antal sider pr. sektion på dag syv:

1. Patienter og bookinger (5) – hvordan en første tid bookes; hvad man gør ved udeblivelse; hvordan en patient skifter terapeut
2. Fakturering og forsikring (4) – hvilke forsikringsselskaber der faktureres direkte; hvordan en kvittering til et udenlandsk forsikringsselskab udstedes; hvornår en session refunderes
3. Behandlingsprotokoller (3) – hvor protokolarkene ligger; hvem der godkender en behandlingsplan; hvad der registreres efter hver session
4. Værktøjer og adgang (2) – hvem der giver adgang til bookingsystemet; hvor skabelonerne til patientbreve ligger
5. Regler og beslutninger (2) – 24-timers-aflysningsreglen; beslutningsloggen
6. Hvem man ringer til (1) – forsikringsselskabernes kontakter; udstyrsservicens telefonlinje

Sytten sider. Det mest stillede spørgsmål – "hvordan udsteder vi en kvittering, et tysk forsikringsselskab vil acceptere?" – var blevet besvaret i receptionen ni gange på et år af den samme faktureringsansvarlige. Siden tog hende femten minutter, fordi det niende svar allerede stod i kanalen og kun manglede ejerlinjen og datoen.

En udfyldt side fra sektion 2:

Hvordan udsteder vi en kvittering, et udenlandsk forsikringsselskab vil acceptere?
Ejer: Faktureringsansvarlig · Sektion: Fakturering og forsikring · Sidst gennemgået: 6. november 2026 · Næste gennemgang: 6. februar 2027
Kort svar: Brug skabelonen "forsikringskvittering" på patientens sprog, med diagnosekoden og terapeutens autorisationsnummer på hver linje.
Gælder for: patienter, der selv betaler og søger refusion hos et forsikringsselskab i udlandet · Gælder ikke for: forsikringsselskaber, vi fakturerer direkte, og som får den månedlige opgørelse.
Sådan: 1. Åbn patienten i bookingsystemet. 2. Vælg skabelonen for forsikringskvittering. 3. Tilføj diagnosekoden fra behandlingsplanen. 4. Kontrollér, at autorisationsnummeret står på hver linje. 5. Send som PDF og gem en kopi i patientens mappe.
Reglen bag: Autorisationsnumre blev tilføjet efter de tyske afslag i april 2026 (beslutningslog, indlæg 2026-04-22).
Undtagelser: En patient, der har brug for en specificeret kvittering pr. session, spørger den faktureringsansvarlige. Ingen andre udsteder en.
Hvor filerne er: Skabelon til forsikringskvittering; liste over diagnosekoder; patientmapper.
Relaterede sider: Hvilke forsikringsselskaber der faktureres direkte; hvornår en session refunderes.

Hvor wikien bor i de værktøjer, du allerede bruger

En organisation med 10–200 medarbejdere bygger sin wiki i den pakke, den allerede betaler for, og hver pakke har et sted til siden, et sted til filerne og en vej for det, et møde efterlader. Hver stopper et forskelligt sted, og i hver er siden på det sprog, den blev skrevet på. Kun dokumenteret adfærd, fra leverandørernes egne sider, med den måned, hver side blev tjekket:

Tre ting er ens i alle fire. Siden er et dokument eller en besked på det ene sprog, den blev skrevet på, og et medlem, der læser et andet sprog, læser enten den eller en kopi, nogen har lavet. Filerne ligger et andet sted og findes med en anden søgning. Og mødet – hvor reglen blev diskuteret og fastlagt – når kun wikien, når en person skriver det ind bagefter. Hvor Teams og Meet overhovedet gemmer en transskription og et resumé, og hvordan man beholder dem efter opkaldet, står i hvor Microsoft Teams og Google Meet gemmer din transskription, optagelse og dit resumé. De AI-notetakere, mange teams tilføjer af samme grund, er sammenlignet i Otter.ai-alternativer, og hver af dem skriver sit resumé på ét sprog.

Den oversættelse, disse pakker dokumenterer, hører til opkaldet eller til læserens skærm, ikke til siden: Microsoft dokumenterer oversatte live-undertekster i Teams-møder, når arrangøren har en Teams Premium- eller Microsoft 365 Copilot-licens, Google dokumenterer oversatte undertekster i Meet på egnede Workspace-planer (begge tjekket august 2026), og WhatsApp dokumenterer oversættelse af en modtaget besked på læserens telefon (tjekket august 2026). Hvad hver af dem dækker, og hvor hver stopper, står i Microsoft Teams live translation, Google Meet live translation og WhatsApp translate. Kvitteringssiden, som den ukrainsktalende terapeut åbner mandag, er et andet objekt end disse undertekster, og den læses på det sprog, den blev skrevet på.

Den wiki, der vokser ud af kanalens historik

InterMIND er et kommunikationsrum, hvor et teams arbejde lever i en kanal, så wikien har et oplagt hjem: kanalen for det team, der bruger den – klinikkens reception, eksportteamet, bureauets kundegruppe – og den kanal er også der, hvor spørgsmålene bliver stillet, og hvor møderne tager deres udgangspunkt. De tre beslutninger ovenfor kan lægges direkte over på den.

Siderne og deres ejere er noter i kanalen. En note er en rich text-besked med overskrifter og nummererede lister, som redigeres senere fra sin egen menu, og som hvert medlem læser på sit eget sprog med originalen ét tryk væk. Fastgjort er sektionsindekset det første, en ny kollega finder. Med redigeringshistorik slået til vises den tidligere ordlyd af en ændret regel over den aktuelle tekst som en forskel på ordniveau med tidsstempel – den gennemgangsspor, som ejerens "sidst gennemgået"-linje peger på. De filer, en side peger på – kvitteringsskabelonen, listen over diagnosekoder, forsikringsselskabets kontrakt – uploades til den samme kanal og har på alle planer et AI-resumé på læserens sprog, hvor hvert punkt er linket til det afsnit, det stammer fra. På betalte planer åbner selve filen oversat til læserens sprog (30 sprog til dokumenter). Hvis masterkopien bliver i et dokumentværktøj, lander dens opdateringer i kanalen via e-mail: kanalens vært giver den en adresse for sig, og en besked sendt dertil vises som en almindelig besked med afsenderen navngivet og vedhæftninger bevaret. Et team, der kommer fra Slack, tager sine kanaler med: en standard Slack-workspace-eksport gendannes som én kanal pr. Slack-kanal, med beskeder i rækkefølge og med deres oprindelige tidsstempler, med fastgjorte beskeder og reaktioner bevaret, og hver besked læses af alle medlemmer på deres eget sprog.

Historikken bag hver side er der, hvor kanalen gør det arbejde, tabellen ovenfor overlader til et menneske. Mødet, hvor reglen fastlægges, starter fra kanalen. Under opkaldet kommer udkastet til siden på alles skærm ved siden af videofelterne med Share to conference – en note, eller et Google Docs- eller OneDrive-dokument linket i chatten – og hver deltager ruller i det uafhængigt og læser det på sit eget sprog, mens den, der deler, redigerer det live. Når opkaldet slutter, skrives recap'en ud fra selve mødet – et resumé, punkterne markeret som aftalt, åbne eller omstridte, action items med ejere, hver linje med sit tidsstempel – og de dokumenter, der blev delt under sessionen, bidrager med deres resuméer sammen med det, der blev sagt. Den ankommer på e-mail, som en besked i kanalen og som et link i kalenderbegivenheden, og hvert indlogget medlem læser den på sit eget sprog: optegnelsen oversættes pr. læser og skrives ikke én gang på det sprog, rummet tilfældigvis brugte. Ethvert medlem kan redigere den, hver redigering bevarer forfatter og revisionshistorik, og kanalen gemmer recap'en fra hver tidligere session – så mødet, der fastlagde reglen om autorisationsnummer, er ét klik fra den side, der angiver den. Det er wikien, der vokser ud af kanalens historik: det niende svar i receptionen, recap'en fra opkaldet, hvor reglen blev diskuteret, skabelonen vedhæftet i april, alt sammen ét sted, med siden øverst. Sat ved siden af tabellen ovenfor er forskellen en ligefrem kendsgerning: de undertekster, disse pakker dokumenterer, oversætter opkaldet, mens det kører. Her er siden, møderne, der frembragte den, dens filer og dens historik én optegnelse, læst af hvert medlem på sit eget sprog.

Spørgsmålskanalen får den samme behandling fra den anden side. Et medlems egen assistent – Claude, ChatGPT, Copilot eller Gemini, forbundet via MCP-connectoren – søger i recaps, transskriptioner, chats og teksten i delte filer i ét spørgsmål, "hvordan udsteder vi en kvittering, et tysk forsikringsselskab vil acceptere?", og returnerer passagerne med det møde, den dato og den fil, hver stammer fra. Dette kører for organisationer med AI-funktioner slået til, og læsning via assistenten er begrænset til de møder og kanaler, medlemmet er med i. Selve chatten har en søgning, og wikien kan tages ud i sin helhed: på alle planer eksporterer en backup fra Indstillinger kanalerne som en ZIP med deres beskeder, transskriptioner og filer – ejerskabsspørgsmålet besvaret på organisationens niveau frem for sidens.

De mennesker, der sidder med et teams viden, er ikke altid ansatte. Forsikringsselskabets sagsbehandler, udstyrsteknikeren, den freelance bogholder, der kender den tyske kvitteringsregel: et eksternt medlem af kanalen kommer ind via e-mail på en gratis konto og læser siderne og deres historik som alle andre. En person uden konto er gæst i ét møde – vedkommende deltager i opkaldet via link, fra en telefon, uden omkostning, hører det live på sit eget sprog og får ingen optegnelse bagefter. Værten stiller rummet til rådighed og betaler på en betalt plan kun for de medlemmer, der har været aktive i de seneste 28 dage – deltaget i et møde, skrevet i en chat eller spurgt assistenten. Medlemmer, der bliver stille, beholder deres adgang uden omkostning, og det er netop, hvad en wiki har brug for: den, der skrev siden for to år siden, kan stadig være i kanalen.

• Åbn en komplet recap – en ægte optegnelse, gengivet af den samme kode, der skriver din.
• Prøv livedemoen – uden tilmelding; tal, og hør rummet oversat pr. lytter.

En intern wiki som håndværk overlever ethvert værktøj: nogen skal stadig indsamle spørgsmålene, holde strukturen til syv sektioner, sætte et navn og en dato på hver side og svare i kanalen i stedet for i en direkte besked. Det, der ikke behøver at overleve, er det andet job – at skrive det, mødet besluttede, ind i wikien igen og holde en oversat kopi af hver side ajour i hånden, ét sprog ad gangen, til de kolleger, der læser det andet.

FAQ

Hvad er en intern wiki?

En intern wiki er en samling sider, en organisation skriver til sine egne medlemmer – hvordan tingene gøres, hvor filerne er, hvad der blev besluttet og hvorfor – samlet ét sted, hvor ethvert medlem kan skrive en side, og enhver side kan linke til en anden. Den adskiller sig fra en offentlig wiki ved sin læser, en kollega frem for en kunde, og fra et intranet ved, at de, der udfører arbejdet, skriver og opdaterer siderne, ikke et centralt team. De sider, der bliver åbnet, er dem, der er organiseret efter de spørgsmål, folk stiller, med en ejer og en gennemgangsdato på hver.

Hvad er forskellen på en intern wiki og en vidensbase?

En wiki er en samling sider, som alle kan skrive i enhver struktur. En vidensbase er organiseret efter de spørgsmål, folk stiller, med ét indlæg pr. spørgsmål og en navngiven ejer og gennemgangsdato på hvert. En wiki bliver til en vidensbase ved at tilføje strukturen og ejerne. Uden dem vokser den til hundredvis af sider, ingen kan navigere i, og ingen har tjekket. Softwaren er ofte den samme, og metoden til at gøre den ene til den anden på 30 dage står i sådan bygger du en vidensbase.

Hvordan opretter man en intern wiki?

Vælg stedet efter, hvor teamet allerede læser, ikke efter en softwaresammenligning. Indsaml de spørgsmål, teamet faktisk stiller, i tre dage, med de ord, der bruges. Sortér dem i højst syv sektioner og navngiv en ejer pr. sektion og pr. side. Skriv de første femten sider ud fra det, der allerede findes – chatsvaret, mødets recap, filen – med en enkeltsides skabelon med kort svar, trin, undtagelser og gennemgangsdato. Fastgør sektionsindekset, hvor teamet læser. Hold derefter løkken kørende: hvert spørgsmål, der besvares to gange, bliver til en side, og hver sides ejer gennemgår den på dens dato.

Hvad bør en intern wiki indeholde?

Én side pr. spørgsmål, hver med spørgsmålet i de ord, folk bruger, en ejer, datoen for sidste gennemgang og datoen for næste, et kort svar, de tilfælde, den gælder og ikke gælder for, trinnene med det system eller den person, de involverer, beslutningen bag reglen med dato, undtagelserne og hvem der afgør dem, links til de aktuelle filer og links til relaterede sider. Wikien som helhed har brug for en struktur på syv sektioner eller færre, organiseret efter de spørgsmål, der stilles, frem for efter afdeling, og et sektionsindeks fastgjort, hvor teamet læser.

Hvad er det bedste værktøj til en intern wiki?

Det, teamet allerede åbner hver dag, for en wiki i et femte værktøj med sit eget login er den wiki, ingen tjekker en mandag. I Microsoft Teams ligger siderne og filerne i kanalen og dens SharePoint-websted, med mødenoter som en Loop-komponent. I Slack er det et canvas i kanalen. I Google Workspace er det et Google Doc linket fra kalenderen. I WhatsApp er det selve gruppechatten – hver med de dokumenterede begrænsninger i tabellen ovenfor, og hver holder siden på det sprog, den blev skrevet på. InterMIND samler et teams noter, filer, chat og mødernes recaps i én kanal, læst af hvert medlem på sit eget sprog, ved siden af disse værktøjer og ikke i stedet for dem.

Kan man bygge en intern wiki i Microsoft Teams?

Ifølge Microsofts dokumentation gemmes et teams filer på et SharePoint-websted, der oprettes sammen med teamet, hvor alle standardkanaler deler webstedet med én mappe pr. kanal, så kanalens fane Filer er der, hvor wikidokumenter bor. Mødenoter er en Loop-komponent, som enhver deltager eller arrangør kan redigere, gemt automatisk og tilgængelig fra Teams-kalenderen og mødets recap. To dokumenterede begrænsninger har betydning for en wiki: eksterne deltagere kan ikke tilgå eller redigere mødenoterne, og chats og kanalbeskeder kan slettes efter en periode af en Teams-opbevaringspolitik, mens filer følger deres egne SharePoint- og OneDrive-politikker (siderne tjekket oktober og november 2026).

Hvordan holder man en intern wiki ajour?

Med en ejer og en gennemgangsdato på hver side og intet andet. Ejerens opgave er at svare på "er det her stadig rigtigt?" en gang i kvartalet og ændre datoen. En side, hvis ejer er gået, får en ny ejer eller bliver fjernet. To vaner fodrer siderne: hvert svar, der gives to gange i teamets kanal, bliver til en side, skrevet af den, der svarede, og hver beslutning, der ændrer en regel, logges først, så siden kan linke til, hvorfor den blev ændret. En wiki, der holdes på den måde, vokser med én side, hver gang et spørgsmål bliver besvaret, og ingen omskriver den som et projekt.

Kilder: Microsoft Learn — Teams and SharePoint integration; Microsoft Learn — Learn about retention for Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Slack — Pricing; Slack — Customize data retention in Slack; Slack — Export your workspace data; Slack — Meeting agenda template (canvas); Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; WhatsApp — How to export your chat history; WhatsApp — Privacy policy; WhatsApp blog — Introducing message translations. Microsoft Learn-siden om Teams og SharePoint er tjekket i november 2026. Siderne om Teams-opbevaring og mødenoter, Slack-siden med canvas-skabelonen og Googles side om "Take notes for me" er tjekket i oktober 2026. Siderne om Teams' beskedoversættelse og undertekster, Slacks sider om priser, opbevaring og eksport, Google Chats oversættelsesside, Meets undertekstside og WhatsApp-siderne er tjekket i august 2026. Leverandører ændrer planer, funktioner og sproglister over tid. Se deres sider for den aktuelle status.