Mal for beslutningslogg: slik registrerer du beslutninger så ingen tar dem opp igjen, og hvor loggen bor (2026)

En beslutningslogg er den løpende oversikten over hva et team har bestemt. Den har én oppføring per beslutning, datert, med beslutningen formulert i én setning, personen eller organet som tok den, alternativene som var på bordet og grunnen til at det valgte vant, hva beslutningen utelukker, og vilkåret for at saken skal vurderes på nytt. Den er verken møtereferatet eller oppgavelisten. Det er dokumentet noen åpner tre måneder senere, når en ny kollega spør «hvorfor gjør vi det på denne måten?», og finner et svar i stedet for et møte.

Denne guiden tar først selve håndverket: hva en beslutningslogg er, hva hver oppføring inneholder, hvordan du skriver den før, under og etter møtet der beslutningen tas, en mal og et register du kan kopiere, og tre utfylte oppføringer. Deretter kommer mekanikken: hvor loggen bor i verktøyene teamet ditt allerede bruker, og hva av beslutningen som faktisk havner i den. Loggens virkelige prøve er nemlig ikke uken den skrives. Det er dagen noen sier «jeg husker ikke at vi ble enige om det».

Hva en beslutningslogg er, og hva den ikke er

Fire typer dokumentasjon kommer ut av et møte, og beslutningsloggen er den som oftest forveksles med de tre andre:

Forskjellen som betyr noe: referater er organisert etter møte, beslutningsloggen etter beslutning. En beslutning som tas over tre møter gir tre oppføringer i referatene og én i loggen. Og loggen beholder det referater vanligvis utelater, nemlig alternativene som tapte og grunnen til at de tapte, fordi det er akkurat det neste diskusjon handler om.

En beslutningslogg er heller ikke en policyhåndbok. En policy er gjeldende regel, mens loggen er historikken over hvordan regelen ble til, også oppføringene merket erstattet. Behold begge, lenk dem sammen, og rediger aldri en gammel oppføring slik at den passer en ny beslutning. Legg heller til en ny oppføring og la den gamle peke til den.

Hva hver oppføring inneholder: formatet

Sju elementer. De fleste maler på nettet har de tre første og stopper der, og det er derfor de fleste logger blir tatt opp til ny debatt:

1. En ID og en dato. «D-14, 9. oktober». ID-en er det folk viser til i chatten («det er D-14») i stedet for å beskrive beslutningen på nytt og åpne den ved et uhell.
2. Beslutningen, i én setning, i presens. «Vi tilbyr kun i EUR.» Ikke «vi diskuterte priser», ikke «man mente at». Hvis setningen trenger et avsnitt, er det to beslutninger eller ingen.
3. Hvem som bestemte, hvem som ble konsultert, hvem som ble informert. Ett navn eller ett organ for beslutningen, de som ga innspill, og kanalen eller listen som fikk beskjed. Den første svarer på «hvem kan endre dette». De to andre svarer på «ble jeg spurt», som er den vanligste grunnen til at en beslutning bestrides.
4. Alternativene som ble vurdert, inkludert det valgte. Én linje hver. En loggoppføring med ett eneste alternativ er en registrering av et utfall, ikke av en beslutning. De avviste alternativene er det som hindrer at det samme forslaget kommer tilbake neste kvartal under nytt navn.
5. Grunnen til at det valgte alternativet vant. Én linje: begrensningen, tallet eller risikoen som avgjorde. Dette er setningen den nye kollegaen faktisk leter etter.
6. Konsekvenser: hva som endres, hva det koster, hva det utelukker. Beslutningen om å tilby kun i EUR utelukker en USD-prisliste. Skriv det, så ingen bygger en.
7. Vilkåret for ny vurdering, og kilden. Datoen, tallet eller hendelsen som legitimt kan åpne saken på nytt («hvis mer enn 10 % av tilbudene avslås på grunn av valuta»), og en lenke til der beslutningen ble tatt: møteoppsummeringen, tråden, øyeblikket i transkripsjonen. En beslutning med et oppgitt vilkår for ny vurdering åpnes på nytt på grunnlag av fakta. En beslutning uten åpnes på nytt på grunnlag av humør.

Det som holdes utenfor: diskusjonen. Tre avsnitt om hvem som sa hva hører hjemme i referatet eller transkripsjonen, og loggen lenker til dem. En oppføring leses av noen som leter etter ett svar, og den bør få plass på én skjerm.

Slik skriver du en: før, under, etter

Før møtet: sett beslutningen på agendaen som en beslutning. Agendapunktet som skal gi oppføringen merkes beslutning, med spørsmålet og alternativene allerede skrevet: «Avgjør: kun EUR, doble prislister eller USD på forespørsel — Lena, 15 min, beslutning.» Halve oppføringen finnes før noen har sagt noe, og rommet bruker minuttene på begrunnelsen i stedet for å rekonstruere alternativene.

Under møtet: les beslutningen opp igjen før dere går videre. Møteleder sier setningen høyt og nevner taperen: «så vi registrerer — kun EUR, doble prislister avvist på grunn av vedlikeholdskostnaden, Lena bestemmer, revurderes hvis avslagene passerer 10 %.» Opplesingen er øyeblikket da oppføringen faktisk blir til. De som kan protestere er i rommet, og en innvending nå er billigere enn den samme innvendingen om seks uker. Et punkt som ikke kan leses opp som én setning, er ikke avgjort ennå. Det merkes åpent med spørsmålet som gjenstår, og går til neste agenda.

Etter møtet: skriv oppføringen samme dag og publiser den der teamet allerede leser. Kopier setningen fra opplesingen, legg til alternativene og begrunnelsen fra notatene, gi den en ID og lenk oppsummeringen. Legg den deretter ut i kanalen der møtet bor, ikke i én persons dokument. En logg i en privat mappe er en logg teamet ikke har, og en beslutning teamet ikke finner, er en beslutning det kommer til å ta på nytt.

Hele disiplinen er opplesingen. Loggen er opplesingen, skrevet ned.

En mal for beslutningslogg

Én oppføring, til et dokument eller et innlegg i en kanal:

D-[nummer] · [dato] · [Beslutning i én setning, presens]
Status: foreslått / besluttet / erstattet av D-[nummer]
Besluttet av: [navn eller organ] · Konsultert: [navn] · Informert: [kanal eller liste]
Kontekst: [to linjer — spørsmålet, og hvorfor det måtte avgjøres nå]
Alternativer: A — [én linje]; B — [én linje]; C — [én linje]. Valgt: [bokstav]
Hvorfor: [den ene begrensningen, tallet eller risikoen som avgjorde]
Konsekvenser: [hva som endres, hva det koster, hva det utelukker]
Revurder hvis: [en dato, et tall eller en hendelse]
Kilde: [lenke til oppsummering eller tråd, og øyeblikket]

Registeret, for listen som strekker seg over året:

Begge kan limes inn i et dokument, et regneark, en canvas eller en chatmelding uten omformatering. Kolonnene som oftest mangler i maler, er Avvist og Revurder hvis, de to som avgjør om oppføringen noensinne blir lest igjen.

Tre utfylte oppføringer

En prisbeslutning — fra ukesmøtet

D-14 · 9. okt. 2026 · Vi tilbyr kun i EUR; en USD-forespørsel får EUR-prisen omregnet til dagens kurs.
Status: besluttet
Besluttet av: Lena · Konsultert: Anna, Mateusz · Informert: #sales
Kontekst: To distributører ba om tilbud i USD i september; det ble foreslått å vedlikeholde en ekstra prisliste.
Alternativer: A — kun EUR; B — doble prislister i EUR/USD; C — USD på forespørsel, omregnet manuelt. Valgt: A
Hvorfor: B dobler vedlikeholdet ved hver prisendring; C har allerede gitt tre inkonsistente tilbud.
Konsekvenser: Ingen USD-prisliste bygges; tilbudsmalen har «EUR» i toppteksten; avslag på grunn av valuta telles.
Revurder hvis: mer enn 10 % av tilbudene i et kvartal avslås på grunn av valuta.
Kilde: Ukesmøtet 9. okt., oppsummering punkt 2, 14:05.

En ansettelsesbeslutning — fra et enkeltstående møte

D-15 · 10. okt. 2026 · Den andre supportansettelsen skal sitte i Lisboa og snakke portugisisk og spansk, ikke være en ny person på kontoret i Milano.
Status: besluttet
Besluttet av: Tomás · Konsultert: Priya, Dana · Informert: #team
Kontekst: Supportsaker fra Spania og Brasil passerte 40 % av køen i tredje kvartal.
Alternativer: A — andre ansettelse i Milano; B — ansette i Lisboa; C — sette ut spansk support. Valgt: B
Hvorfor: C ble avvist på grunn av overleveringskvaliteten i piloten; A lar den spanske køen bli som den er.
Konsekvenser: Stillingsannonsen er på portugisisk og spansk; onboarding skjer eksternt; teamets arbeidsspråk i supportkanalen forblir blandet.
Revurder hvis: andelen spanske og portugisiske saker faller under 20 % i to kvartaler.
Kilde: Ansettelsesmøtet 10. okt., oppsummering punkt 3.

En beslutning som er erstattet

D-9 · 14. aug. 2026 · Kundesamtaler tas opp som standard.
Status: erstattet av D-16
D-16 · 13. okt. 2026 · Kundesamtaler tas bare opp når kunden har sagt ja i invitasjonen; oppsummeringen skrives uansett.
Besluttet av: Lena · Konsultert: Kenji (juridisk), Anna · Informert: #sales, #team
Alternativer: A — beholde opptak som standard; B — spørre i invitasjonen; C — slutte å ta opp kunder. Valgt: B
Hvorfor: to kunder protesterte i september; det er oppsummeringen, ikke opptaket, teamet faktisk leser i etterkant.
Konsekvenser: Invitasjonsmalen får én setning til; D-9 er lukket, ikke slettet.
Revurder hvis: en kundekontrakt krever opptak.
Kilde: Ukesmøtet 13. okt., oppsummering punkt 1, 03:40.

Legg merke til hva de tre har til felles: en setning en utenforstående kan handle på, taperen nevnt med begrunnelse, og et vilkår som sier når spørsmålet legitimt er åpent igjen. Det er hele håndverket. Alt annet i denne guiden handler om å gjøre at oppføringen kan finnes igjen etter at møtet er over.

Hvorfor beslutninger tas opp igjen

Team åpner sjelden en beslutning på nytt fordi de er uenige i den. De åpner den fordi dokumentasjonen ikke kan svare på ett av fire spørsmål:

• «Bestemte vi egentlig det?» Utfallet ble diskutert, men aldri lest opp, så alle gikk derfra med sin egen versjon. Løsningen er opplesingen, ikke et bedre dokument.
• «Hvorfor bestemte vi det?» Setningen overlevde, begrunnelsen gjorde ikke det. Seks uker senere er grunnen glemt, beslutningen virker vilkårlig, og forslaget som tapte, kommer tilbake som om det var nytt. Løsningen er linjene Hvorfor og Avvist.
• «Ble jeg spurt?» Noen som er berørt, ble ikke konsultert eller informert, og bestrider beslutningen for å bli hørt, ikke for å endre den. Løsningen er linjene Konsultert og Informert, og å publisere oppføringen der den personen leser.
• «Har noe endret seg?» En beslutning uten vilkår for ny vurdering åpnes på nytt når noen har lyst. En med vilkår åpnes når vilkåret er oppfylt, og ellers vises det til ID-en. Løsningen er linjen Revurder hvis.

En logg med alle sju elementene lukker alle fire spørsmålene. En som bare har setningen, lukker det første og åpner de tre andre.

Hvor beslutningsloggen bor i verktøyene du allerede bruker

Hver av de store plattformene har et sted der en beslutning kan skrives ned, og hver stopper på et ulikt punkt. Kun dokumentert oppførsel, fra leverandørenes egne sider, med måneden hver side ble kontrollert:

To ting er likt overalt. Beslutningen er en linje en person skriver inn i et dokument ved siden av møtet, på det ene språket rommet brukte. Og begrunnelsen, de avviste alternativene og øyeblikket det ble sagt står bare i dokumentet hvis den personen skrev dem ned.

Slik kommer en beslutning tilbake som oppsummeringen

InterMIND er et rom for daglig kommunikasjon der et møte bor i en kanal, så loggen har et åpenbart hjem: kanalens chat. Der legges agendaen inn dagen før og oppføringene postes etterpå, og der skriver hvert medlem på sitt eget språk og leser de andre på sitt. Hvis registeret holdes et annet sted, i et regneark eller et dokument, kan oppdateringene havne i kanalen via e-post: kanalens vert gir den en egen adresse, og en melding sendt dit vises som en vanlig melding med avsenderen nevnt og vedlegg bevart.

Under samtalen vises oppføringen som diskuteres på alles skjerm ved siden av videorutene med Share to conference: den som deler redigerer notatet live mens rommet ser opplesingen ta form, og hver deltaker leser den på sitt eget språk, med originalen ett klikk unna.

Når samtalen er over, skrives oppsummeringen fra selve møtet. Den har en oversikt og viktigste punkter, deretter punktene — hvert merket avtalt, åpent eller omstridt, med talerne knyttet til og et tidsstempel som åpner transkripsjonen på øyeblikket det ble sagt — så aksjonspunktene med ansvarlige og de åpne spørsmålene. Det er råmaterialet til en loggoppføring: setningen, hvem som sa ja, hvem som var uenig og hvor, og øyeblikket du kan lenke til som Kilde. Oppsummeringen kommer på e-post, som en melding i kanalen og som en lenke i kalenderhendelsen, og hvert innlogget medlem leser den på sitt eget språk: protokollen oversettes per leser, den skrives ikke én gang på språket rommet tilfeldigvis brukte. Alle medlemmer kan redigere den, hver endring beholder forfatter og revisjonshistorikk, og kanalen beholder oppsummeringen av hver tidligere økt, så møtet der D-14 ble besluttet, er ett klikk unna oppføringen som viser til det.

Der oppføringen må ende opp i et journalsystem, legger verten til en kopi av oppsummeringen til en hvilken som helst adresse — en innkommende postboks i et CRM- eller oppgavesystem — og hver oppsummering av møtet eller kanalen sendes også dit etter en engangsbekreftelse av adressen. Mekanikken står i en kopi av hver møteoppsummering i CRM-et ditt, på e-post. Den samme oppsummeringen når Zapier, en webhook eller API-et, med sammendraget som Markdown, og et medlems egen assistent — Claude, ChatGPT, Copilot eller Gemini — kan søke i oppsummeringene via MCP-koblingen. Dermed er «hva bestemte vi om USD-tilbud?» et spørsmål som stilles i verktøyet de allerede bruker, og besvares med oppsummeringen og øyeblikket.

En gjest blir med via lenke, uten konto og uten kostnad — fra telefon, i nettleseren — og hører møtet live på sitt eget språk. Det finnes ingen oversikt for en gjest i etterkant; kontoen er gratis, og det er den som gjør at oversikten blir tilgjengelig. Verten stiller rommet til rådighet og betaler, på et betalt abonnement, bare for medlemmene som har vært aktive de siste 28 dagene. Medlemmer som blir stille, beholder tilgangen uten kostnad.

• Åpne en fullstendig oppsummering — en ekte oversikt gjengitt av den samme koden som skriver din, med punkter og tidsstempler.
• Prøv live-demoen — uten registrering; snakk, og hør rommet oversatt per lytter.

Beslutningsloggen som håndverk overlever alle verktøy: noen må fortsatt si setningen høyt, nevne alternativet som tapte, og skrive ned når spørsmålet kan stilles igjen. Det som ikke trenger å overleve, er den andre jobben, å rekonstruere hvem som ble enige om hva fra hukommelsen, på ett språk, for folk som leser på andre.

FAQ

Hva er en beslutningslogg?

En beslutningslogg er den løpende oversikten over et teams beslutninger, med én oppføring per beslutning: beslutningen i én setning, datoen, hvem som tok den, hvem som ble konsultert og informert, alternativene som ble vurdert og grunnen til at det valgte vant, hva den utelukker, vilkåret som ville åpne den på nytt, og en lenke til der den ble tatt. Den er organisert etter beslutning, ikke etter møte, og det er det som skiller den fra referater.

Hva bør en beslutningslogg inneholde?

Sju ting per oppføring: en ID og en dato; beslutningen i én setning i presens; hvem som bestemte, hvem som ble konsultert og hvem som ble informert; alternativene som ble vurdert, inkludert de avviste; grunnen til at det valgte alternativet vant; konsekvensene — hva som endres og hva som utelukkes; og vilkåret for ny vurdering pluss en lenke til kilden. De to som oftest utelates, er de avviste alternativene og vilkåret for ny vurdering, og det er de to som hindrer at en beslutning åpnes på nytt.

Hvordan skriver man en beslutningslogg?

Sett beslutningen på agendaen som en beslutning, med alternativene skrevet på forhånd. I møtet leser du beslutningen opp høyt før dere går videre — setningen, taperen og grunnen til at den tapte, hvem som bestemmer, når den revurderes. Samme dag skriver du oppføringen fra opplesingen, gir den en ID, lenker oppsummeringen og legger den ut der teamet allerede leser. En logg skrevet fra opplesinger er nøyaktig; en som rekonstrueres en uke senere fra hukommelsen, er starten på neste diskusjon.

Hva er forskjellen mellom en beslutningslogg og en handlingslogg?

En beslutningslogg registrerer hva som ble bestemt og hvorfor. En handlingslogg, eller en liste med aksjonspunkter, registrerer hva noen skal gjøre på grunn av det, med en ansvarlig og en dato. «Vi tilbyr kun i EUR» er en beslutning; «Anna — oppdater tilbudsmalen til EUR — innen 16. oktober» er handlingen den ga. Beslutninger siteres i måneder, aksjonspunkter lukkes på dager. Å ha begge i én liste er slik begrunnelsene går tapt under oppgavene.

Hva er et beslutningsregister?

Det samme som en beslutningslogg, i språket fra prosjekt- og styringsarbeid: en tabell med én rad per beslutning — ID, dato, beslutning, hvem som bestemte, hvorfor, status. «Register» betegner gjerne tabellvisningen og «logg» den løpende; tabellen i denne guiden er begge deler, med Avvist og Revurder hvis lagt til de vanlige kolonnene.

Finnes det en mal for beslutningslogg i Excel eller Word?

Registeret i denne guiden er en vanlig tabell og oppføringen er ren tekst; begge kan limes inn i Excel, Google Sheets, Word, en Slack-canvas, en Loop-side eller en chatmelding uten omformatering. Formatet betyr mer enn filen: det som holder loggen, trenger en rad per beslutning med begrunnelsen og de avviste alternativene, og det må ligge der teamet allerede leser.

Hvem bør føre beslutningsloggen?

Møteleder for møtet der beslutningen tas, skriver oppføringen samme dag, fra opplesingen; personen som står under Besluttet av, eier selve beslutningen. I en liten organisasjon er det vanligvis samme person for de fleste oppføringene. Viktigere enn rollen er stedet: én logg for teamet, i kanalen teamet allerede bruker, ikke én per person.

Hva er en architecture decision record?

En architecture decision record, eller ADR, er programvareutviklingens form for en loggoppføring: ett kort dokument per beslutning, lagret i prosjektets repositorium, med kontekst, beslutning og konsekvenser, og en status som går fra foreslått via akseptert til erstattet. Malen i denne guiden er den samme tanken for et teams driftsbeslutninger, med menneskene lagt til — hvem som bestemte, hvem som ble konsultert, hvem som fikk beskjed — fordi det utenfor ingeniørfaget er det som blir bestridt.

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 notatside, Googles Meet-hjelpeside og Slacks mal ble kontrollert oktober 2026; Zooms side om møteoppsummering ble kontrollert august 2026; Googles kunngjøring om next steps ble kontrollert september 2026. Leverandørene endrer abonnementer, funksjoner og språklister over tid; se sidene deres for gjeldende status.