Skabelon til beslutningslog: sådan noterer du beslutninger, så ingen genåbner dem — og hvor loggen bor (2026)

En beslutningslog er den løbende fortegnelse over, hvad et team har besluttet: én post pr. beslutning, dateret, med beslutningen formuleret i én sætning, den person eller det organ, der traf den, de muligheder, der lå på bordet, og hvorfor den valgte vandt, hvad beslutningen udelukker, og hvilken betingelse der vil få den taget op igen. Den er ikke referatet, og den er ikke opgavelisten. Det er dokumentet, man åbner tre måneder senere, når en ny kollega spørger: "Hvorfor gør vi det på den her måde?", og finder et svar i stedet for et møde.

Denne guide tager først håndværket: hvad en beslutningslog er, hvad hver post indeholder, hvordan du skriver den før, under og efter mødet, hvor beslutningen træffes, en skabelon og et register, du kan kopiere, og tre udfyldte poster. Derefter kommer mekanikken: hvor loggen bor i de værktøjer, dit team allerede bruger, og hvad af beslutningen der faktisk kommer med. Loggens egentlige prøve er nemlig ikke den uge, den skrives. Det er dagen, hvor nogen siger: "Jeg kan ikke huske, at jeg har sagt ja til det."

Hvad en beslutningslog er — og hvad den ikke er

Der kommer fire slags optegnelser ud af et møde, og beslutningsloggen er den, der oftest forveksles med de tre andre:

Forskellen, der tæller: referater er organiseret efter møde, beslutningsloggen er organiseret efter beslutning. En beslutning, der træffes over tre møder, giver tre referatindførsler og én logpost. Og loggen bevarer det, referater typisk udelader — de muligheder, der tabte, og hvorfor de tabte — fordi det er netop den del, den næste diskussion handler om.

En beslutningslog er heller ikke en politikmanual. En politik er den gældende regel; loggen er historien om, hvordan reglen blev til, inklusive de poster, der er markeret som afløst. Behold begge, link dem sammen, og redigér aldrig en gammel post, så den passer til en ny beslutning — tilføj en ny post, og lad den gamle pege på den.

Hvad hver post indeholder: formatet

Syv elementer. De fleste skabeloner på nettet har de tre første og stopper der, og det er derfor, de fleste logs bliver genforhandlet:

1. Et ID og en dato. "D-14, 9. oktober". ID'et er det, folk henviser til i chatten ("det er D-14") i stedet for at genfortælle beslutningen og ved et uheld genåbne den.
2. Beslutningen i én sætning, i nutid. "Vi tilbyder kun i EUR." Ikke "vi drøftede prissætning" og ikke "man mente, at". Hvis sætningen kræver et afsnit, er det to beslutninger eller ingen.
3. Hvem der besluttede, hvem der blev hørt, og hvem der fik besked. Ét navn eller ét organ for beslutningen; de personer, hvis input blev indhentet; den kanal eller liste, der blev informeret. Det første svarer på "hvem kan ændre det her"; de to andre svarer på "blev jeg spurgt" — den mest almindelige grund til, at en beslutning bliver anfægtet.
4. De overvejede muligheder, også den valgte. Én linje hver. En logpost med kun én mulighed er en optegnelse af et resultat, ikke af en beslutning; det er de afviste muligheder, der forhindrer det samme forslag i at komme igen næste kvartal under nyt navn.
5. Hvorfor den valgte mulighed vandt. Én linje — den begrænsning, det tal eller den risiko, der afgjorde det. Det er den sætning, den nye kollega faktisk leder efter.
6. Konsekvenser: hvad der ændres, hvad det koster, hvad det udelukker. Beslutningen om kun at tilbyde i EUR udelukker en USD-prisliste; skriv det, så ingen bygger en.
7. Genåbningsbetingelsen og kilden. Den dato, det tal eller den hændelse, der legitimt ville genåbne den ("hvis mere end 10 % af tilbuddene afvises på grund af valuta"), og et link til stedet, hvor den blev truffet — møde-recappen, tråden, øjeblikket i transskriptionen. En beslutning med en angivet genåbningsbetingelse genåbnes på grundlag af beviser; en beslutning uden genåbnes på grundlag af stemning.

Det, der ikke hører hjemme: diskussionen. Tre afsnit om, hvem der sagde hvad, hører til i referatet eller transskriptionen, og loggen linker til dem. En post læses af én, der leder efter ét svar; den skal kunne være på én skærm.

Sådan skriver du den: før, under, efter

Før mødet: sæt beslutningen på dagsordenen som en beslutning. Det dagsordenspunkt, der skal give posten, markeres som beslutning, med spørgsmålet og mulighederne allerede skrevet: "Beslut: kun EUR, dobbelte prislister eller USD på forespørgsel — Lena, 15 min., beslutning." Halvdelen af posten findes, før nogen har sagt noget, og rummet bruger sine minutter på begrundelsen i stedet for at rekonstruere mulighederne.

Under mødet: læs beslutningen op, før I går videre. Facilitatoren siger sætningen højt, med taberen nævnt: "så vi noterer — kun EUR, dobbelte prislister afvist på grund af vedligeholdelsesomkostninger, Lena beslutter, genåbnes hvis afvisninger overstiger 10 %." Oplæsningen er det øjeblik, hvor posten egentlig bliver til; de, der kunne have indvendinger, er i rummet, og en indvending nu er billigere end den samme indvending om seks uger. Et punkt, der ikke kan læses op som én sætning, er ikke besluttet endnu — det markeres som åbent med det spørgsmål, der er tilbage, og går videre til næste dagsorden.

Efter mødet: skriv posten samme dag, og udgiv den, hvor teamet allerede læser. Kopiér oplæsningssætningen, tilføj mulighederne og begrundelsen fra notaterne, giv den et ID, og link recappen. Del den derefter — i den kanal, hvor mødet bor, ikke i én persons dokument. En log i en privat mappe er en log, teamet ikke har, og en beslutning, teamet ikke kan finde, er en beslutning, det vil træffe igen.

Hele disciplinen er oplæsningen. Loggen er oplæsningen skrevet ned.

En skabelon til beslutningslog

Én post, til et dokument eller et kanalopslag:

D-[nummer] · [dato] · [Beslutning i én sætning, nutid]
Status: foreslået / besluttet / afløst af D-[nummer]
Besluttet af: [navn eller organ] · Hørt: [navne] · Informeret: [kanal eller liste]
Kontekst: [to linjer — spørgsmålet, og hvorfor det skulle afgøres nu]
Muligheder: A — [én linje]; B — [én linje]; C — [én linje]. Valgt: [bogstav]
Hvorfor: [den ene begrænsning, det tal eller den risiko, der afgjorde det]
Konsekvenser: [hvad der ændres, hvad det koster, hvad det udelukker]
Genåbnes hvis: [en dato, et tal eller en hændelse]
Kilde: [link til recap eller tråd, og øjeblikket]

Registeret, til listen der spænder over hele året:

Begge kan indsættes i et dokument, et regneark, et canvas eller en chatbesked uden omformatering. De kolonner, der oftest mangler i skabeloner, er Afvist og Genåbnes hvis — de to, der afgør, om posten nogensinde bliver læst igen.

Tre udfyldte poster

En prisbeslutning — fra ugemødet

D-14 · 9. okt. 2026 · Vi tilbyder kun i EUR; en USD-forespørgsel får EUR-prisen omregnet til dagens kurs.
Status: besluttet
Besluttet af: Lena · Hørt: Anna, Mateusz · Informeret: #sales
Kontekst: To distributører bad om USD-tilbud i september; det blev foreslået at vedligeholde en ekstra prisliste.
Muligheder: A — kun EUR; B — dobbelte EUR/USD-prislister; C — USD på forespørgsel, omregnet i hånden. Valgt: A
Hvorfor: B fordobler vedligeholdelsen ved hver prisændring; C har allerede givet tre inkonsistente tilbud.
Konsekvenser: Der bygges ingen USD-prisliste; tilbudsskabelonen har "EUR" i sin overskrift; afvisninger på grund af valuta tælles.
Genåbnes hvis: mere end 10 % af tilbuddene i et kvartal afvises på grund af valuta.
Kilde: Ugemøde, 9. okt., recap punkt 2, 14:05.

En ansættelsesbeslutning — fra et enkeltstående møde

D-15 · 10. okt. 2026 · Den anden supportansættelse placeres i Lissabon, portugisisk- og spansktalende, ikke som endnu en person på kontoret i Milano.
Status: besluttet
Besluttet af: Tomás · Hørt: Priya, Dana · Informeret: #team
Kontekst: Supporthenvendelser fra Spanien og Brasilien udgjorde over 40 % af køen i 3. kvartal.
Muligheder: A — anden ansættelse i Milano; B — ansæt i Lissabon; C — outsource spansk support. Valgt: B
Hvorfor: C blev afvist på grund af overdragelseskvaliteten i pilotforløbet; A lader den spanske kø blive, hvor den er.
Konsekvenser: Stillingsopslaget er på portugisisk og spansk; onboarding sker på afstand; teamets arbejdssprog i supportkanalen forbliver blandet.
Genåbnes hvis: andelen af spanske og portugisiske henvendelser falder under 20 % i to kvartaler.
Kilde: Ansættelsesopkald, 10. okt., recap punkt 3.

En afløst beslutning

D-9 · 14. aug. 2026 · Kundeopkald optages som standard.
Status: afløst af D-16
D-16 · 13. okt. 2026 · Kundeopkald optages kun, når kunden har sagt ja i invitationen; recappen skrives i begge tilfælde.
Besluttet af: Lena · Hørt: Kenji (jura), Anna · Informeret: #sales, #team
Muligheder: A — fortsæt med at optage som standard; B — spørg i invitationen; C — stop med at optage kunder. Valgt: B
Hvorfor: to kunder gjorde indsigelse i september; det er recappen, ikke optagelsen, teamet faktisk læser bagefter.
Konsekvenser: Invitationsskabelonen får én ekstra sætning; D-9 er lukket, ikke slettet.
Genåbnes hvis: en kundekontrakt kræver optagelser.
Kilde: Ugemøde, 13. okt., recap punkt 1, 03:40.

Læg mærke til, hvad de tre har til fælles: en sætning, en fremmed kan handle på, taberen nævnt med sin begrundelse og en betingelse, der siger, hvornår spørgsmålet legitimt er åbent igen. Det er hele håndværket. Alt andet i denne guide handler om at gøre posten mulig at finde, når mødet er slut.

Hvorfor beslutninger bliver genforhandlet

Teams genåbner sjældent en beslutning, fordi de er uenige i den. De genåbner den, fordi optegnelsen ikke kan besvare et af fire spørgsmål:

• "Besluttede vi faktisk det?" Resultatet blev diskuteret, men aldrig læst op, så hver person gik med sin egen version. Løsningen er oplæsningen, ikke et bedre dokument.
• "Hvorfor besluttede vi det?" Sætningen overlevede, begrundelsen gjorde ikke. Seks uger senere er begrundelsen ukendt, beslutningen ser vilkårlig ud, og det forslag, der tabte, kommer igen, som om det var nyt. Løsningen er linjerne Hvorfor og Afvist.
• "Blev jeg spurgt?" En berørt person blev ikke hørt eller ikke informeret og anfægter beslutningen for at blive hørt snarere end for at få den ændret. Løsningen er linjerne Hørt og Informeret — og at udgive posten, hvor den person læser.
• "Har noget ændret sig?" En beslutning uden genåbningsbetingelse genåbnes, når som helst nogen har lyst; en med betingelse genåbnes, når betingelsen er opfyldt, og ellers henvises der til den med ID. Løsningen er linjen Genåbnes hvis.

En log med alle syv elementer lukker alle fire spørgsmål. En log med kun sætningen lukker det første og åbner de tre andre.

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

Hver af de store platforme har et sted, hvor en beslutning kan skrives ned, og hver stopper et forskelligt sted. Kun dokumenteret adfærd, fra leverandørernes egne sider, med den måned hver side blev kontrolleret:

To ting er ens overalt. Beslutningen er en linje, en person taster ind i et dokument ved siden af mødet, på det ene sprog, rummet brugte; og begrundelsen, de afviste muligheder og øjeblikket, hvor det blev sagt, er kun i dokumentet, hvis personen har skrevet dem ned.

Hvordan en beslutning kommer tilbage som recap

InterMIND er et rum til kommunikation, hvor et møde bor i en kanal, så loggen har et oplagt hjem: kanalens chat, hvor dagsordenen blev lagt ind dagen før, og hvor posterne slås op bagefter — og hvor hvert medlem skriver på sit eget sprog og læser de andres på sit. Hvis registeret opbevares et andet sted, i et regneark eller et dokument, kan dets opdateringer lande 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æftede filer bevaret.

Under opkaldet kommer den post, der drøftes, op på alles skærm ved siden af videofelterne med Share to conference: den, der deler, redigerer noten live, mens rummet ser oplæsningen tage form, og hver deltager læser den på sit eget sprog, med originalen et klik væk.

Når opkaldet er slut, skrives recappen ud fra selve mødet. Den indeholder et overblik og de vigtigste pointer, derefter punkterne — hvert markeret aftalt, åbent eller omstridt, med de talende tilknyttet og et tidsstempel, der åbner transskriptionen i det øjeblik, det blev sagt — og så action items med ejere og de åbne spørgsmål. Det er råmaterialet til en logpost: sætningen, hvem der sagde ja, hvem der var uenig og hvor, og det øjeblik, der skal linkes som Kilde. Recappen 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, den 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 recappen fra alle tidligere sessioner, så mødet, hvor D-14 blev truffet, er ét klik fra den post, der henviser til det.

Hvor posten skal ende i et system of record, tilføjer værten en recapkopi til en vilkårlig adresse — en CRM- eller trackerpostkasse til indgående post — og hver recap af mødet eller kanalen sendes også dertil efter en engangsbekræftelse af adressen; mekanikken står i en kopi af hver mødereacp i dit CRM, på e-mail. Den samme recap når frem til Zapier, en webhook eller API'et med opsummeringen som Markdown, og et medlems egen assistent — Claude, ChatGPT, Copilot eller Gemini — kan søge i recaps via MCP-connectoren, så "hvad besluttede vi om USD-tilbud?" bliver et spørgsmål, man stiller i det værktøj, man allerede bruger, og får besvaret med recappen og dens øjeblik.

En gæst deltager via link, uden konto og uden omkostning — fra en telefon, i browseren — og hører mødet live på sit eget sprog. Der er ingen optegnelse til en gæst bagefter — kontoen er gratis, og det er den, der gør optegnelsen tilgængelig. Værten stiller rummet til rådighed og betaler på et betalt abonnement kun for de medlemmer, der har været aktive de seneste 28 dage; medlemmer, der bliver stille, beholder deres adgang uden omkostning.

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

Beslutningslogning som håndværk overlever ethvert værktøj: nogen skal stadig sige sætningen højt, nævne den mulighed, der tabte, og skrive ned, hvornår spørgsmålet må stilles igen. Det, der ikke behøver at overleve, er det andet job — at rekonstruere ud fra hukommelsen, hvem der har sagt ja til hvad, på ét sprog, for folk der læser på andres.

FAQ

Hvad er en beslutningslog?

En beslutningslog er den løbende fortegnelse over et teams beslutninger, én post pr. beslutning: beslutningen i én sætning, datoen, hvem der traf den, hvem der blev hørt og informeret, de overvejede muligheder og hvorfor den valgte vandt, hvad den udelukker, den betingelse der vil genåbne den, og et link til stedet, hvor den blev truffet. Den er organiseret efter beslutning, ikke efter møde, og det er det, der adskiller den fra et referat.

Hvad bør en beslutningslog indeholde?

Syv ting pr. post: et ID og en dato; beslutningen i én sætning i nutid; hvem der besluttede, hvem der blev hørt, og hvem der blev informeret; de overvejede muligheder, også de afviste; begrundelsen for, at den valgte mulighed vandt; konsekvenserne — hvad der ændres, og hvad der udelukkes; samt genåbningsbetingelsen plus et link til kilden. De to, der oftest udelades, er de afviste muligheder og genåbningsbetingelsen, og det er netop dem, der forhindrer en beslutning i at blive genåbnet.

Hvordan skriver man en beslutningslog?

Sæt beslutningen på dagsordenen som en beslutning, med mulighederne skrevet på forhånd. På mødet læses beslutningen højt, før I går videre — sætningen, taberen og dens begrundelse, hvem der beslutter, og hvornår den tages op igen. Samme dag skriver du posten ud fra oplæsningen, giver den et ID, linker recappen og deler den, hvor teamet allerede læser. En log, der er skrevet ud fra oplæsninger, er præcis; en, der rekonstrueres en uge senere ud fra hukommelsen, er begyndelsen på den næste diskussion.

Hvad er forskellen på en beslutningslog og en handlingslog?

En beslutningslog registrerer, hvad der blev besluttet, og hvorfor; en handlingslog — eller en liste med action items — registrerer, hvad nogen vil gøre på grund af det, med en ejer og en dato. "Vi tilbyder kun i EUR" er en beslutning; "Anna — opdater tilbudsskabelonen til EUR — senest 16. oktober" er den handling, den gav. Beslutninger henvises der til i månedsvis; action items lukkes i løbet af dage. At have begge dele på én liste er den måde, begrundelserne forsvinder under opgaverne.

Hvad er et beslutningsregister?

Det samme som en beslutningslog, i projekt- og governance-arbejdets ordforråd: en tabel med én række pr. beslutning — ID, dato, beslutning, hvem der besluttede, hvorfor, status. "Register" betyder som regel tabelvisningen og "log" den løbende; tabellen i denne guide er begge dele, med Afvist og Genåbnes hvis føjet til de sædvanlige kolonner.

Findes der en skabelon til beslutningslog i Excel eller Word?

Registeret i denne guide er en almindelig tabel, og posten er almindelig tekst; begge kan indsættes i Excel, Google Sheets, Word, et Slack-canvas, en Loop-side eller en chatbesked uden omformatering. Formatet betyder mere end filen: det, der rummer loggen, skal have en række pr. beslutning med begrundelsen og de afviste muligheder, og det skal bo, hvor teamet allerede læser.

Hvem bør føre beslutningsloggen?

Facilitatoren for det møde, hvor beslutningen træffes, skriver posten samme dag ud fra oplæsningen; den person, der står under Besluttet af, ejer selve beslutningen. I en lille organisation er det som regel den samme person for de fleste poster. Det, der betyder mere end rollen, er stedet: én log for teamet, i den kanal teamet allerede bruger, ikke én pr. person.

Hvad er en architecture decision record?

En architecture decision record, eller ADR, er softwareudviklingens form for en beslutningslogpost: ét kort dokument pr. beslutning, opbevaret i projektets repository, med konteksten, beslutningen og dens konsekvenser og en status, der bevæger sig fra foreslået over accepteret til afløst. Skabelonen i denne guide er den samme idé til et teams driftsbeslutninger, med personerne — hvem der besluttede, hvem der blev hørt, hvem der fik besked — føjet til, fordi det uden for softwareudvikling er det, der bliver anfægtet.

Kilder: Microsoft — Take meeting notes in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" now captures "next steps"; Slack — Meeting agenda template (canvas). Microsofts notesside, Googles Meet-hjælpeside og Slacks skabelon er kontrolleret i oktober 2026; Zooms side om mødeopsummering i august 2026; Googles meddelelse om next steps i september 2026. Leverandører ændrer abonnementer, funktioner og sproglister over tid; tjek deres sider for den aktuelle status.