Sådan opbygger du en vidensbase på 30 dage: struktur, kilder, ejerskab – og den base, der vokser ud af det, teamet allerede siger (2026)

En vidensbase er den samling svar, en organisation giver mere end én gang, skrevet ned én gang og opbevaret der, hvor den, der har brug for svaret, kan finde det uden at spørge. »Hvordan fakturerer vi en distributør i Schweiz?«, »hvad siger vi til en forælder, hvis barn har overskredet fristen?«, »hvilken transportør skal vi bruge til paller til Marokko?« – når et af disse spørgsmål stilles for fjerde gang, har organisationen en vidensbase, uanset om den har bygget en eller ej. Den findes bare i en enkelt kollegas hoved og i et dusin chattråde.

De fleste guides til at bygge en starter med valget af software. Denne starter tidligere, for softwaren er det mindst vigtige: en vidensbase er tre beslutninger – en struktur, et sæt kilder og et navn på hvert indlæg – og en måned til at tage dem i rækkefølge. Planen på 30 dage nedenfor fører en organisation med 10–200 medarbejdere frem til en base, folk faktisk åbner. Den indeholder en indlægsskabelon, du kan kopiere, et gennemarbejdet eksempel og en tabel over, hvor basen lever i de værktøjer, dit team allerede bruger. Til sidst kommer den del, de fleste guides springer over: basen er for det meste allerede skrevet, i det teamet siger i sine møder og skriver i sine chats, og opgaven er at samle det ét sted, så alle på teamet kan læse det.

Hvad en vidensbase er – og hvad den ikke er

Fire ting kaldes en vidensbase, og forvekslingen mellem dem er grunden til, at så mange bygges og så få bruges:

Vidensbasen er den første række, og den afhænger af de tre andre. Wikien er det, den bliver til uden struktur. Dokumentbiblioteket er der, hvor dens filer ligger. Chathistorikken er der, hvor de fleste af dens indlæg første gang bliver skrevet, ved et tilfælde, som svar. Håndværket er at flytte et svar fra den fjerde række til den første – én gang, med et navn på – og metoden nedenfor er bygget op omkring det træk.

To yderligere sondringer har betydning, før man begynder at bygge. En intern vidensbase er til teamet: hvordan vi gør tingene, hvor tingene er, hvad vi har besluttet. En ekstern er til kunderne: hvordan produktet virker, hvad man gør, når noget fejler. Denne guide handler om den interne. En ekstern base skrives senere ud fra den interne ved at omskrive de indlæg, kunderne må se. Og en vidensbase er ikke et procesdokument eller en SOP: de beskriver et helt arbejde fra ende til anden, mens et indlæg besvarer ét spørgsmål og linker til proceduren, når svaret er »følg den«.

De tre beslutninger: struktur, kilder, ejerskab

Struktur: efter spørgsmål, ikke efter afdeling. Den, der spørger »hvordan fakturerer vi Schweiz?«, ved ikke, om svaret hører under økonomi, salg eller logistik. De kender spørgsmålet. En base, der er organiseret efter afdeling, sender dem ind i tre sektioner for at finde ét svar. Organisér efter de spørgsmål, folk stiller – med deres egne ord – og hold øverste niveau på syv sektioner eller færre. Ud over syv har selve strukturen brug for en søgning, og en søgning i en base, ingen har fyldt endnu, returnerer ingenting. Typiske topniveauer for en lille organisation: kunder og ordrer; penge og fakturering; mennesker og ansættelser; værktøjer og adgang; regler og beslutninger; hvem man ringer til.

Kilder: det, der allerede findes, før noget nyt. Ingen har tid til at skrive en vidensbase fra et blankt ark, og det behøver heller ingen. Svarene findes – i det svar, en kollega gav i tirsdags, i referatet fra det møde, hvor reglen blev fastlagt, i den prisliste, nogen vedhæftede en besked i marts, i de introduktionsnoter, den sidste nyansatte førte. Den første version af de fleste indlæg er kopieret, ikke skrevet. Hvor kilderne ligger, og hvor meget af hver der kan genfindes senere, er emnet for tabellen længere nede. Kort fortalt er chat, filer og mødenoter i de fleste pakker tre forskellige steder, og selve mødet er det, der efterlader mindst.

Ejerskab: et navn og en dato på hvert indlæg. Det eneste, der adskiller en vidensbase, folk har tillid til, fra en, de er holdt op med at åbne, er om et indlæg siger, hvem der ejer det, og hvornår det sidst blev kontrolleret. Et indlæg med et navn og »gennemgået 14. oktober 2026« bliver troet. Den samme tekst uden dem er »nok forældet«. Ejerens opgave er lille: én gang i kvartalet svare på »er det her stadig rigtigt?« og ændre datoen. Det er ikke at omskrive basen. Hvis ingen kan nævnes som ejer af et indlæg, er indlægget ikke viden, men et gæt, og det skal ud.

Sådan opbygger du en vidensbase på 30 dage

Planen forudsætter én person som drivkraft – teamlederen eller den, der får flest spørgsmål – der bruger omkring to timer om ugen, mens resten af teamet bruger minutter.

Uge 1 – saml spørgsmålene, ikke svarene. Opret en kanal, eller en note i en eksisterende, og lad alle i syv dage smide hvert spørgsmål ind, de har stillet en kollega eller er blevet stillet, med de ord, der blev brugt. Ingen svar endnu. Om fredagen er der fyrre til firs spørgsmål, og en tredjedel er dubletter. Tæl gentagelserne: det spørgsmål, der er stillet fem gange, er indlæg nummer ét. Der, hvor listen ligger, er også der, hvor basen skal ligge. Valget af sted træffes her ud fra det, teamet allerede åbner hver dag, ikke ud fra en softwaresammenligning.

Uge 2 – strukturen og ejerne. Sortér spørgsmålene i grupper. Grupperne er sektionerne, og der er højst syv. Udpeg en ejer pr. sektion – den, der besvarede flest af sektionens spørgsmål i uge 1. Udpeg derefter en ejer pr. indlæg for de tyve mest stillede spørgsmål. Skriv ikke andet end listen endnu: sektion, spørgsmål, ejer. Send den til teamet og bed om én ting: »hvilke spørgsmål mangler?« Listen kommer tilbage med ti flere.

Uge 3 – de første tyve indlæg, ud fra kilder. Hver ejer skriver sine indlæg med skabelonen nedenfor og tager udgangspunkt i det, der allerede findes: chatsvaret, referatet, filen. Reglen for uge 3 er »kort og sandt slår langt og komplet«: et svar på to sætninger med et link til filen, dateret og underskrevet, er et indlæg. En side, der forklarer reglens historie, er et dokument og kan komme senere. Indlæg, der afhænger af en beslutning, ingen kan finde, kommer først i beslutningsloggen og derefter i basen med et link.

Uge 4 – udgiv, og kør løkken. Fastgør basen, hvor teamet læser. Indfør derefter de to vaner, der holder den i live: hvert spørgsmål, der fra nu af stilles i spørgsmålskanalen, får et indlæg eller et link til et, skrevet af den, der besvarede det. Og hver ejer får gennemgangsdatoen i sin kalender. Dag 30 er ikke en færdig base. Det er tyve til tredive indlæg, hver med ejer og dato, og en løkke, der tilføjer et nyt, hver gang et spørgsmål bliver besvaret. Seks måneder senere er det to hundrede, og ingen har skrevet det som et projekt.

Det, der ikke sker i løbet af de 30 dage: at flytte dokumentbiblioteket, at vælge et nyt værktøj eller at skrive en side til hver proces. Basen peger på filer, hvor de ligger, og på procedurer, hvor de bor. At flytte dem er et andet projekt, og ofte et unødvendigt et.

En skabelon til vidensbaseartikler

Ét indlæg, ét spørgsmål, under en side. Kopiér den som en note og udfyld den. De linjer, der oftest springes over, er de sidste tre, og det er dem, der holder indlægget sandt.

[Spørgsmål, 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, der hver nævner det system, den person eller den fil, der er involveret]
Reglen bag: [den beslutning, der fastlagde den, med dato, og hvorfor]
Undtagelser: [tilfældene uden for den normale vej, og hvem der afgør hvert af dem]
Hvor filerne er: [link til den aktuelle skabelon, prisliste, kontrakt]
Relaterede indlæg: [SOP'en, processen, den tidligere version]

Skabelonen er almindelig 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 gennemarbejdet eksempel: en eksportørs base efter 30 dage

En italiensk maskineksportør med 38 medarbejdere, et salgskontor i Milano og distributører i Spanien, Rumænien og Marokko. Uge 1 gav 61 spørgsmål, efter fjernelse af dubletter 44. Strukturen, der kom ud af dem, med antal indlæg pr. sektion på dag 30:

1. Distributører og ordrer (7) – hvordan en ny distributør oprettes; hvem der godkender en kreditgrænse; hvad en ordre skal have, før den går til produktion
2. Fakturering og betaling (5) – fakturering af en distributør i Schweiz; hvornår en proforma bruges; hvad man gør, når en betaling er 30 dage forsinket
3. Forsendelse og told (6) – transportører pr. destination; de dokumenter, en palle til Marokko skal have; hvem der underskriver eksportangivelsen
4. Service og garanti (4) – hvad garantien dækker; hvordan et servicebesøg bookes; hvilke reservedele der holdes på lager
5. Værktøjer og adgang (3) – hvem der giver adgang til CRM'et; hvor prislisten ligger; hvordan man når den fælles postkasse
6. Regler og beslutninger (3) – to-underskriftsreglen over 10.000; rabatloftet; beslutningsloggen
7. Hvem man ringer til (2) – toldmægleren; transportørkontakterne pr. land

Tredive indlæg. Det mest stillede spørgsmål i uge 1 – »hvilke dokumenter skal en palle til Marokko have?« – var blevet besvaret i kanalen elleve gange i løbet af et år af den samme logistikleder. Indlægget tog hende tyve minutter, fordi det ellevte svar allerede var skrevet og kun manglede ejerlinjen og datoen.

Et udfyldt indlæg fra sektion 3:

Hvilke dokumenter skal en palle til Marokko have?
Ejer: Logistikleder · Sektion: Forsendelse og told · Sidst gennemgået: 3. november 2026 · Næste gennemgang: 3. februar 2027
Kort svar: Handelsfaktura i tre eksemplarer, pakkeliste, EUR.1-certifikat og distributørens importlicensnummer på fakturaen.
Gælder for: alle forsendelser til marokkanske distributører · Gælder ikke for: reservedele under 1.000 EUR med kurer, som sendes med kurerens egen formular.
Sådan: 1. Eksportér fakturaen fra systemet med Marokko-skabelonen. 2. Tilføj licensnummeret fra distributørens fil. 3. Anmod om EUR.1 hos handelskammeret, tre hverdage. 4. Vedhæft pakkelisten. 5. Send sættet til toldmægleren og send kopi til distributøren.
Reglen bag: Licensnummeret blev tilføjet efter tilbageholdelsen i Casablanca i marts 2026 (beslutningslogindlæg 2026-03-19).
Undtagelser: Demonstrationsmaskiner sendes under midlertidig indførsel; logistiklederen afgør det.
Hvor filerne er: Marokko-fakturaskabelon; EUR.1-anmodningsformular; distributørfiler.
Relaterede indlæg: Transportører pr. destination; hvem der underskriver eksportangivelsen.

Hvor vidensbasen lever i de værktøjer, du allerede bruger

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

Tre ting er ens i alle fire. Indlægget er et dokument eller en besked på det ene sprog, det blev skrevet på, og et medlem, der læser et andet sprog, læser enten det eller en kopi, nogen har lavet. Filerne er et andet sted, fundet med en anden søgning. Og mødet – hvor reglen blev diskuteret og fastlagt – når kun basen, hvis 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 optegnelsen: Microsoft dokumenterer live oversatte 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 kontrolleret august 2026), og WhatsApp dokumenterer oversættelse af en modtaget besked på læserens telefon (kontrolleret august 2026). Hvad hver af dem dækker, og hvor hver af dem stopper, står i Microsoft Teams live translation, Google Meet live translation og WhatsApp translate. Det indlæg, distributørens ekspedient i Casablanca åbner mandag, er et andet objekt end disse undertekster, og det læses på det sprog, det blev skrevet på.

Den base, der vokser ud af det, teamet allerede siger

InterMIND er et kommunikationsrum, hvor et teams arbejde lever i en kanal, så vidensbasen har et oplagt hjem: kanalen for det team, der bruger den – eksportteamet, klinikkens reception, bureauets kundegruppe – og den kanal er også spørgsmålskanalen og det sted, hvor møderne starter fra. De tre beslutninger ovenfor svarer direkte til den.

Struktur og ejerskab er selve indlæggene. Opslået som en note – en rich text-besked med overskrifter og nummererede lister, der senere redigeres fra sin egen menu – læses et indlæg af hvert medlem på deres eget sprog med originalen et klik væk, og det fastgøres, så den aktuelle version er 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, og det er det gennemgangsspor, ejerens »sidst gennemgået«-linje peger på. De filer, et indlæg peger på – prislisten, Marokko-skabelonen, distributørkontrakten – uploades til den samme kanal og får 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 egen adresse, og en besked sendt dertil vises som en almindelig besked med afsenderen nævnt og vedhæftninger bevaret. Et team, der kommer fra Slack, tager sine kanaler med: en standard Slack-workspace-eksport genskabes som én kanal pr. Slack-kanal, med beskeder i rækkefølge med deres oprindelige tidsstempler, fastgjorte beskeder og reaktioner bevaret, og hver besked læses af hvert medlem på deres eget sprog.

Kilder er der, hvor kanalen gør det arbejde, tabellen ovenfor overlader til en person. Mødet, hvor reglen fastlægges, starter fra kanalen. Under opkaldet vises udkastet til indlægget på alles skærm ved siden af videoflisen 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 live. Når opkaldet slutter, skrives referatet ud fra selve mødet – et resumé, de punkter, der er markeret som aftalt, åbne eller omstridte, handlingspunkterne med ejere, hver linje med sit tidsstempel – og de dokumenter, der blev delt under sessionen, bidrager med deres resuméer ved siden af det, der blev sagt. Det kommer med e-mail, som en besked i kanalen og som et link i kalenderbegivenheden, og hvert logget ind medlem læser det på sit eget sprog: optegnelsen oversættes pr. læser, den skrives ikke én gang på det sprog, rummet tilfældigvis brugte. Ethvert medlem kan redigere det, hver redigering bevarer forfatter og revisionshistorik, og kanalen gemmer referatet fra hver tidligere session – så mødet, der fastlagde Marokko-reglen, er ét klik fra det indlæg, der angiver den. Det er basen, der vokser ud af det, teamet allerede siger: det ellevte svar i kanalen, referatet fra opkaldet, hvor reglen blev diskuteret, filen vedhæftet i marts, alt sammen ét sted, med indlægget øverst.

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 referater, transskriptioner, chats og teksten i delte filer med ét spørgsmål, »hvilke dokumenter skal en palle til Marokko have?«, og returnerer passagerne med det møde, den dato og den fil, hver stammer fra. Det 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 basen kan tages ud i sin helhed: på alle planer eksporterer en backup fra Indstillinger kanalerne som en ZIP med deres beskeder, transskriptioner og filer, hvilket besvarer ejerskabsspørgsmålet på organisationens niveau frem for på indlæggets. 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 indlægget, de møder, der frembragte det, dets filer og dets historik én optegnelse, læst af hvert medlem på deres eget sprog.

De mennesker, der sidder med et teams viden, er ikke altid ansatte. Distributørens ordreekspedient, toldmægleren, den freelance bogholder, der kender den schweiziske regel: et eksternt medlem af kanalen deltager via e-mail på en gratis konto og læser indlæggene og deres historik som alle andre. En person uden konto er gæst i ét møde – de deltager i opkaldet via link, fra en telefon, uden omkostning, hører det live på deres 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 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 vidensbase har brug for: den, der skrev indlægget for to år siden, kan stadig være i kanalen.

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

At bygge en vidensbase som håndværk overlever ethvert værktøj: nogen skal stadig samle spørgsmålene, holde strukturen på syv sektioner, sætte et navn og en dato på hvert indlæg og svare i kanalen i stedet for i en direkte besked. Det, der ikke behøver at overleve, er det andet arbejde – at gentaste det, mødet besluttede, ind i basen og at føre en oversat kopi af hvert indlæg i hånden, ét sprog ad gangen, til det kontor, der læser det andet.

FAQ

Hvad er en vidensbase?

En vidensbase er en samling svar på de spørgsmål, en organisation får mere end én gang, skrevet ned én gang, hver med en ejer og en dato, og opbevaret der, hvor den, der har brug for svaret, kan finde det uden at spørge en kollega. En intern vidensbase besvarer teamets egne spørgsmål – hvordan vi fakturerer, hvor filerne er, hvad vi har besluttet. En ekstern besvarer kunders spørgsmål om et produkt. Den adskiller sig fra en wiki ved at have en struktur og ejere, og fra et dokumentbibliotek ved at rumme svar frem for filer.

Hvordan opretter man en vidensbase?

Saml de spørgsmål, teamet faktisk stiller, i en uge, med de ord, der bruges. Gruppér dem i højst syv sektioner. Udpeg en ejer til hver sektion og til hver af de tyve mest stillede spørgsmål. Lad ejerne skrive de indlæg ud fra det, der allerede findes – chatsvar, mødereferater, filer – med en skabelon på én side med et kort svar, trin, undtagelser og en gennemgangsdato. Udgiv det på det sted, teamet allerede læser. Hold derefter løkken kørende, så hvert besvaret spørgsmål bliver til et indlæg, og hver ejer gennemgår sit indlæg på dets dato.

Hvad bør en vidensbase indeholde?

Ét indlæg pr. spørgsmål, hver med spørgsmålet med de ord, folk bruger, en ejer, datoen for sidste gennemgang og datoen for næste, et kort svar, de tilfælde det gælder og ikke gælder for, trinnene med angivelse af det system eller den person, der er involveret, beslutningen bag reglen med dens dato, undtagelserne og hvem der afgør dem, links til de aktuelle filer og links til relaterede indlæg. Basen som helhed har brug for en struktur på syv sektioner eller færre, organiseret efter de stillede spørgsmål frem for efter afdeling.

Hvad er forskellen på en vidensbase og en wiki?

En wiki er et sæt 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 kan omdannes til en vidensbase ved at tilføje strukturen og ejerne. Uden dem vokser en wiki til hundredvis af sider, ingen kan navigere i, og ingen har kontrolleret. Softwaren er ofte den samme. Forskellen er de to beslutninger.

Hvordan strukturerer man en vidensbase?

Efter spørgsmål, ikke efter afdeling: den, der spørger, ved ikke, hvilken afdeling svaret hører til, men ved, hvad de spørger om. Gruppér de spørgsmål, der blev samlet i den første uge, i højst syv sektioner på øverste niveau – for en lille organisation typisk kunder og ordrer, penge og fakturering, mennesker og ansættelser, værktøjer og adgang, regler og beslutninger samt hvem man ringer til – og hold hvert indlæg til ét spørgsmål. Hvis en sektion vokser ud over omkring tredive indlæg, så del den efter de spørgsmål, folk stiller, frem for efter hvem der svarer på dem.

Hvor lang tid tager det at bygge en vidensbase?

Tredive dage til en base, folk åbner: en uge til at samle spørgsmål, en uge til struktur og ejere, en uge til at skrive de første tyve indlæg ud fra eksisterende kilder, en uge til at udgive og sætte gennemgangsløkken i gang. Drivkraften bruger omkring to timer om ugen, og hver ejer bruger tyve minutter pr. indlæg, fordi de fleste indlæg er kopieret fra et svar, der allerede er givet, frem for skrevet nyt. Basen er ikke færdig på dag 30. Den vokser med ét indlæg, hver gang et spørgsmål bliver besvaret.

Kan man bygge en vidensbase gratis?

Ja – skabelonen i denne guide er almindelig tekst, og basen kan leve i en note, et dokument eller en kanal i de værktøjer, et team allerede bruger: et canvas i Slack, et Google Doc, fanen Filer i en Teams-kanal, en fastgjort note i en chat. Det, der ikke koster noget i software, koster stadig ejernes gennemgangstid, og grænserne er pakkens egne: Slacks Free-plan beholder 90 dages beskedhistorik, og i hver pakke står indlægget på det sprog, det blev skrevet på. I InterMIND er Basic-planen gratis, og priserne for betalte planer står på prissiden.

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 kontrolleret i november 2026. Siderne om Teams-opbevaring og mødenoter, Slack-canvasskabelonsiden og Googles »Take notes for me«-side er kontrolleret i oktober 2026. Siderne om Teams-beskedoversættelse og undertekster, Slacks pris-, opbevarings- og eksportsider, Google Chats oversættelsessider og Meet-undertekstsiderne samt WhatsApp-siderne er kontrolleret i august 2026. Leverandører ændrer planer, funktioner og sprogoversigter over tid; tjek deres sider for den aktuelle status.