Mall för processdokumentation: så dokumenterar du en process så att den följs (2026)

Processdokumentation är den skriftliga beskrivningen av hur ett arbete rör sig genom din organisation, från händelsen som startar det till resultatet som avslutar det: faserna i ordning, den roll som äger varje fas, vad som går från en roll till nästa, vad varje fas lämnar efter sig och vad som händer när den normala vägen är blockerad. En mall för processdokumentation är det fasta skelett som orden hamnar i, så att den tionde processen läses som den första och den som har läst en kan hitta i alla.

De flesta processer är redan dokumenterade någonstans: i ett diagram från en workshop för två år sedan, på en wikisida som ingen öppnar, i huvudet på den enda person som har gjort det sedan början. Problemet är sällan att dokumentet saknas. Det är att det inte följs, och de tre orsakerna till det är desamma i alla organisationer. Den här guiden tar först hantverket: vad ett processdokument är och inte är, standardformatet, en mall du kan kopiera och ett genomarbetat exempel. Sedan kommer de tre orsakerna och vad som åtgärdar var och en, var dokumentet och dess genomgång bor i de verktyg ditt team redan använder, och vad kollegan som läser det på ett annat språk får. Ett processdokument bedöms nämligen en morgon då en ny kundansvarig, en ny sjuksköterska eller en ny distributörs expeditör ska lämna över något till nästa person och inte vet vem det är.

Vad ett processdokument är – och vad det inte är

Tre dokument beskriver hur arbete utförs på processnivå. De förväxlas ofta med varandra och med rutinerna under dem:

Kartan är bilden, processdokumentet är texten som gör bilden användbar och SOP:erna är detaljerna under varje ruta. Skillnaden avgör längden: ett processdokument som förklarar var man klickar för varje steg är en manual som ingen läser, och en processkarta utan text är en bild som alla tolkar olika. SOP:n, dess mall och dess översynscykel finns i SOP template och how to write an SOP. Den här guiden handlar om nivån ovanför, den som säger var SOP:erna behövs och vem som lämnar vad till vem.

Ett processdokument är inte heller en beskrivning av hur arbetet vanligtvis går till. Det är det överenskomna sättet, med en ägare, en version och ett översynsdatum. Därför är en fas som ingen följer en fas att ändra eller ett samtal att ta, inte en mening att låta stå kvar.

Vad som ska ingå: standardformatet

Ett användbart processdokument har ett huvud och åtta avsnitt. De flesta mallar på nätet har syfte, steg och ett diagram och slutar där, vilket är skälet till att de flesta processdokument läses en gång och sedan aldrig mer:

Huvudet är dokumentets identitet, fem fält på en rad: ett ID som folk kan hänvisa till ("PR-HR-02"), en version ("v1.3"), ägaren (en namngiven person som ansvarar för hela processen, inte en avdelning), ikraftträdandedatum och nästa översynsdatum. En process utan översynsdatum ses över när något går fel.

1. Syfte och resultat. En eller två meningar: vad processen levererar, till vem och hur bra ser ut, med en siffra om du har en. "En nyanställd har konton, utrustning, en plan och en utsedd fadder första dagen, och en 30-dagarsuppföljning senast dag 30."
2. Utlösare och sluttillstånd. Händelsen som startar processen och resultatet som avslutar den. "Startar när det undertecknade avtalet läggs i HR-mappen; slutar när 30-dagarsuppföljningen är registrerad." Allt mellan de två meningarna är processen; allt utanför är ett annat dokument. Om processen inte har ett tydligt slut är det två processer.
3. Omfattning. När processen gäller och när den inte gör det, med angränsande processer angivna med ID. "Anställda med avtal hos oss, i vilket land som helst. Inte: konsulter (PR-HR-04); inte: interna förflyttningar (PR-HR-06)."
4. Roller. Varje roll som förekommer i faserna, med vad den äger. Roller, inte namn, så att dokumentet överlever en nyanställning. En av dem är processägaren, som ansvarar för hela flödet, inklusive de överlämningar som ingen äger som standard.
5. Faser och överlämningar. Dokumentets hjärta: faserna i ordning, var och en med rollen som utför den, vad som kommer in (input), vad som lämnar den och var det registreras (output), vem det går till och tidsgränsen. Överlämningen skrivs ut uttryckligen, "till: IT, senast dag −5", eftersom överlämningen är det ställe där processer brister: båda sidor tror att den andra har det.
6. Undantag och eskalering. Grenarna utanför huvudspåret: vad som händer när tillståndet är sent, kreditkontrollen misslyckas eller ägaren är borta. Varje undantag namnger en roll eller en person som avgör, aldrig "fråga någon". Sista raden täcker det du missade: "Allt som inte täcks här: processägaren avgör, och ärendet tas upp vid nästa översyn."
7. Mått. Två eller tre siffror som ägaren bevakar: ledtid från utlösare till sluttillstånd, antal ärenden per månad, andelen som hamnade i ett undantag. Ingen dashboard, utan de siffror som talar om för ägaren att processen driver iväg innan någon klagar.
8. Relaterade dokument och versionshistorik. SOP:erna under varje fas, policyn som processen genomför, länken till kartan; därefter en rad per version: datum, vad som ändrades, vem som godkände. Historiken är det som hindrar att samma misstag återinförs under ett nytt versionsnummer.

Det som lämnas utanför: motiveringen till varje regel (policyns uppgift), detaljerna klick för klick i en fas (SOP:ns uppgift) och allt som en person inte kan agera på. "Vi värnar om en smidig introduktion" är en känsla, inte en fas.

Så dokumenterar du en process så att den följs

Tre orsaker förklarar nästan varje processdokument som inte följs, och var och en har en åtgärd som hör till skrivandet, inte till någon senare tillsyn.

Orsak ett: det beskriver processen som den är designad, inte som den körs. Dokumentet skrevs i en workshop av dem som leder arbetet, och de som utför det har en annan version, med kalkylbladet vid sidan av och kollegan som rings upp vid fas 3. Åtgärden är att kartlägga utifrån belägg innan du skriver. Följ tre verkliga ärenden från utlösare till sluttillstånd och skriv ner vad som faktiskt hände: mejlen, meddelandena, formulären, väntetiderna. Om processen lever i en gruppchatt, med beställningar från distributörer som kommer in på WhatsApp eller skiftbyten som överenskoms i en Telegram-grupp, är chatten beviset och genomgången börjar med dess historik. Vad Export chat ger dig och var den tar slut står i how to export a WhatsApp chat. Där de tre ärendena skiljer sig åt finns anledningen till att dokumentet existerar. Avgör för varje skillnad om den är en fas att åtgärda i texten eller ett samtal att ta med teamet.

Orsak två: ingen kan hitta den aktuella versionen. Dokumentet ligger i en mapp med fyrtio andra, en kopia finns på någons skrivbord, en tredje version finns i wikin, och personen som behöver den en tisdagsmorgon frågar en kollega i stället. Åtgärden är att publicera där teamet redan läser, med huvudet synligt. En plats, den aktuella versionen först, ägarens namn och översynsdatumet överst, så att "stämmer det här fortfarande?" besvaras av huvudet och inte av att fråga runt. Faserna skrivs som överlämningar mellan roller, så att var och en hittar sin egen fas och de två intill på under en minut.

Orsak tre: det ändrades och de vars fas ändrades fick aldrig veta det. En översyn flyttade kreditkontrollen före plockningen, eller lade till ett steg för anställda som flyttar, och dokumentet uppdaterades, men lagret och de rekryterande cheferna fortsatte göra som förut. Åtgärden är att gå igenom processen med dem som kör den och avisera varje ändring med de rader som ändrats. Genomgången är ett möte: ägaren och en person per roll, den aktuella versionen på allas skärmar, varje fas uppläst av den som utför den, varje överlämning bekräftad av båda sidor. Det genomgången ändrar blir en ny version med en rad i historiken, och de tre rader som ändrats går till dem vars faser de berör, på den plats de redan läser, samma dag. Ett beslut som ändrar en regel i stället för en fas hamnar dessutom i decision log, med process-ID i posten.

Sekvensen blir alltså: välj en process med tydlig start och slut; följ tre verkliga ärenden; skissa faserna först, i mallen, med överlämningarna utskrivna; fyll i undantagen utifrån vad ärendena visade; gå igenom den med en person per roll; publicera där teamet läser, med ägaren och översynsdatumet i huvudet; lägg översynsdatumet i kalendern. Dokumentet som kommer ut av detta följs eftersom det är sant, lätt att hitta och aviserat, de tre egenskaper som mallen ensam inte kan ge det.

En mall för processdokumentation

[Process-ID] — [Processnamn]
Version: [n.n] · Ägare: [namn, roll] · Gäller från: [datum] · Nästa översyn: [datum]

1. Syfte och resultat
[En eller två meningar: vad processen levererar, till vem och hur bra ser ut, med en siffra om du har en.]

2. Utlösare och sluttillstånd
Startar när: [händelsen] · Slutar när: [resultatet som nu finns]

3. Omfattning
Omfattar: [ärenden, platser, kunder, länder] · Omfattar inte: [vad en annan process hanterar, med dess ID]

4. Roller
Processägare: [den enda person som ansvarar för hela flödet]
[Roll] — [vad den äger i den här processen]
[Roll] — [vad den äger i den här processen]

5. Faser och överlämningar
5.1 [Fas] — [roll] — in: [vad som kommer in] — ut: [vad som lämnar, var det registreras] — till: [nästa roll] — senast: [tidsgräns]
5.2 [Fas] — [roll] — in: … — ut: … — till: … — senast: …
5.3 [Fas] — [roll] — in: … — ut: … — till: … — senast: …

6. Undantag och eskalering
Om [villkor]: [vad som händer, vem som avgör]
Om [villkor]: [vad som händer, vem som avgör]
Allt som inte täcks här: [roll] avgör; ärendet tas upp vid nästa översyn.

7. Mått
[Två eller tre siffror som ägaren bevakar (ledtid, ärenden per månad, andel som hamnade i ett undantag) och var de läses av.]

8. Relaterade dokument och versionshistorik
SOP:er: [ID:n, en per fas där det behövs] · Genomför: [policy] · Karta: [länk till diagrammet]
v[n.n] — [datum] — [vad som ändrades] — godkänd av [namn]
v[n.n] — [datum] — [vad som ändrades] — godkänd av [namn]

Mallen är ren text med fetstilta etiketter, så den kan klistras in i en Word-fil, ett Google Doc, en wikisida, en Slack canvas eller en chattanteckning utan omformatering. De två avsnitt som oftast lämnas tomma är överlämningarna ("till vem, senast när") och översynsdatumet. Det är de två som avgör om processen fortfarande körs som dokumentet säger om ett år.

Ett genomarbetat exempel: introduktion av en nyanställd, från undertecknat avtal till dag 30

Ett företag med sextio personer och anställda i tre länder; processen korsar fyra roller och slutar när 30-dagarsuppföljningen är registrerad.

PR-HR-02 — Introduktion av en nyanställd
Version: 1.3 · Ägare: Driftchef, Inés M. · Gäller från: 1 okt 2026 · Nästa översyn: 1 apr 2027

1. Syfte och resultat — En nyanställd har fungerande konton, utrustning, en plan för första månaden och en utsedd fadder första dagen, och en registrerad 30-dagarsuppföljning senast dag 30, oavsett i vilket land hen börjar.
2. Utlösare och sluttillstånd — Startar när: det undertecknade avtalet läggs i HR-mappen. Slutar när: 30-dagarsuppföljningen är registrerad i den anställdes akt.
3. Omfattning — Anställda med avtal hos oss, i vilket land som helst, på kontor eller på distans. Inte: konsulter (PR-HR-04); interna förflyttningar (PR-HR-06).
4. Roller — Processägare: driftchefen. HR: akten, dokumenten, lönen, välkomstpaketet. IT: konton, utrustning, behörigheter. Rekryterande chef: planen, faddern, avstämningarna. Ekonomi: löneuppsättning.

5. Faser och överlämningar
5.1 Öppna akten — HR — in: det undertecknade avtalet — ut: introduktionsposten med startdatum, land, chef, språk; välkomstpaketet skickat på den anställdes språk — till: IT och den rekryterande chefen — senast: två arbetsdagar efter undertecknandet
5.2 Konton och utrustning — IT — in: posten — ut: konton skapade, laptop skickad till den anställdes adress, behörigheter enligt rollprofilen; bekräftelse i posten — till: HR — senast: fem arbetsdagar före startdatum
5.3 Dokument och lön — HR, därefter ekonomi — in: posten, den anställdes dokument (tillstånd eller registrering där landet kräver det) — ut: den anställde i lönesystemet, dokument i akten — till: den rekryterande chefen — senast: startdatum
5.4 Första månaden, planerad — rekryterande chef — in: posten — ut: en 30-dagarsplan i akten, en utsedd fadder, första veckan i den anställdes kalender, välkomstsamtalet bokat med teamet — till: den anställde, dag ett — senast: dagen före start
5.5 Dag ett — rekryterande chef och fadder — in: planen — ut: välkomstsamtalet hållet, planen genomgången, den anställdes öppna frågor loggade i teamets kanal — till: den anställde — senast: slutet av dag ett
5.6 Avstämningar — rekryterande chef — in: planen, de loggade frågorna — ut: en avstämning dag 7 och en dag 30, 30-dagarsuppföljningen registrerad i akten — till: HR, för att stänga posten — senast: dag 30

6. Undantag — Tillstånd eller registrering inte klart till startdatum: den anställde börjar med de uppgifter som chefen markerar som tillåtna utan det; HR äger uppföljningen och datumet förs in i posten. Laptop inte levererad dag −2: IT skickar en lånedator ur kontorets lager; driftchefen informeras samma dag. Anställd i ett land där vi inte har anställt tidigare: fas 5.3 pausas; driftchefen avgör inom tre arbetsdagar vilken väg via employer of record som väljs (PR-HR-05).
7. Mått — Arbetsdagar från undertecknande till färdiga konton (mål ≤ 7); andel anställda med registrerad 30-dagarsuppföljning senast dag 30 (mål 100 %); frågor loggade under vecka ett, lästa vid kvartalsöversynen för att se vilken fas som fortsätter att ge upphov till dem.
8. Relaterat — SOP-IT-03 "Nya konton och behörigheter"; SOP-HR-08 "Löneuppsättning per land"; Introduktionspolicy §2; karta: simbanediagrammet i HR-mappen.
v1.3 — 1 okt 2026 — välkomstpaketet skickas nu på den anställdes språk; avstämning dag 7 tillagd — godkänd av Inés M.
v1.2 — 3 jun 2026 — laptopleverans flyttad till fem dagar före start efter två sena leveranser — godkänd av Inés M.

Lägg märke till vad exemplet gör. Varje fas namnger rollen, vad som kommer in, vad som lämnar och var det registreras, vem som får det härnäst och senast när, så att en överlämning som inte skedde syns som en tom ruta i posten och inte som en överraskning dag ett. Varje undantag namnger vem som avgör. Måtten är tre siffror, inte en dashboard. Och historiken förklarar varför faserna ser ut som de gör: fas 5.2 har sitt datum eftersom två laptops var sena, och avstämningen dag 7 finns eftersom 30-dagarsuppföljningen gång på gång hittade frågor som borde ha besvarats under första veckan.

Ett kortare andra exempel, formen på en försäljningsprocess för en exportör med distributörer:

PR-SA-01 — Order till leverans · Ägare: Exportchef · Startar när: en distributörs order kommer in · Slutar när: leveransen är bekräftad och fakturan skickad
1. Ordergranskning — kundansvarig — in: ordern — ut: order bekräftad i systemet, eller en fråga tillbaka till distributören — till: ekonomi — senast: en arbetsdag
2. Kreditkontroll — ekonomi — in: den bekräftade ordern — ut: frisläppt, eller spärrad med en orsak — till: lager — senast: en arbetsdag
3. Plock och packning — lager — in: den frisläppta ordern — ut: packad, med packlista — till: logistik — senast: tre arbetsdagar
4. Dokument och frakt — logistik — in: den packade ordern — ut: försändelsen bokad, destinationens dokument bifogade, spårning i systemet — till: ekonomi och kundansvarig — senast: en arbetsdag
5. Faktura och bekräftelse — ekonomi, därefter kundansvarig — in: försändelsen — ut: faktura skickad; leverans bekräftad med distributören och registrerad — Om krediten är spärrad: kundansvarig ringer distributören inom en arbetsdag; exportchefen avgör om ordern ska frisläppas eller betalas i förskott.

Tolv rader, och en ny expeditör hos distributören och en ny person på lagret vet båda vem de väntar på.

Var processdokumentet och dess genomgång bor i de verktyg du redan använder

Själva dokumentet bor där teamets dokument bor: en Word-fil i ett delat bibliotek, ett Google Doc, en sida i en wiki, en canvas i en kanal. Genomgången är ett möte, och varje plattform har en plats för det genomgången lämnar efter sig; var och en tar slut vid olika punkter. Endast dokumenterat beteende, från leverantörernas egna sidor, med den månad då varje sida kontrollerades:

Två saker är desamma överallt. Processdokumentet är en fil på det enda språk den skrevs på, och kollegan som läser ett annat språk läser den eller en kopia som någon har gjort. Och det genomgången ändrade når dokumentet först när en person skriver in det i efterhand, på samma språk. Översättningen som de här sviterna dokumenterar hör till samtalet, inte till dokumentet: Microsoft dokumenterar översatta liveundertexter i Teams-möten när arrangören har en Teams Premium- eller Microsoft 365 Copilot-licens, och Google dokumenterar översatta undertexter i Meet i behöriga Workspace-planer (båda kontrollerade augusti 2026). Vad var och en täcker och var var och en tar slut står i Microsoft Teams live translation och Google Meet live translation. Processen som den nya expeditören öppnar på tisdagen, och genomgången som ändrade den, är andra objekt än de undertexterna, och de läses på det språk de skrevs på.

Så förblir processen, dess genomgång och dess historik läsbara för varje medlem

InterMIND är ett utrymme för kommunikation där ett teams arbete bor i en kanal, så det färdiga processdokumentet har ett självklart hem: kanalen för teamet som kör processen, en kanal för människorna på HR, IT, ekonomi och de rekryterande cheferna som var och en äger en fas. Postas det som en anteckning, ett rich text-meddelande med rubriker och numrerade listor som redigeras senare från sin egen meny, läser varje medlem det på sitt eget språk med originalet ett klick bort, och det fästs så att den aktuella versionen är det första en ny kollega hittar. Med redigeringshistorik påslagen visas den tidigare formuleringen av en ändrad fas ovanför den aktuella texten som en diff på ordnivå med tidsstämpel. Laddas det upp som en fil, en PDF eller ett Word-dokument, får det på alla planer en AI-sammanfattning på läsarens språk med varje punkt länkad till stycket den kom från, så att enssidesläsningen finns innan någon har skrivit den. På betalda planer öppnas själva filen översatt till läsarens språk (30 språk för dokument). Om originalet stannar i ett dokumentverktyg landar dess uppdateringar i kanalen via e-post: kanalens värd ger den en egen adress, och ett meddelande som skickas dit visas som ett vanligt meddelande med avsändaren namngiven och bilagor bevarade.

Genomgången utgår från den kanalen. Under samtalet läggs den aktuella versionen på allas skärmar bredvid videorutorna med Share to conference, en anteckning eller ett Google Docs- eller OneDrive-dokument länkat i chatten, och varje deltagare skrollar den oberoende och läser den på sitt eget språk. En delad anteckning redigeras live av den som delar medan rummet ser den ändrade överlämningen ta form. När samtalet tar slut skrivs sammanfattningen utifrån själva mötet: en sammanfattning, punkterna markerade som överenskomna, öppna eller omstridda, action items med ägare, varje rad med sin tidsstämpel kvar, och dokumenten som delades under sessionen bidrar med sina sammanfattningar vid sidan av det som sades. Den kommer med e-post, som ett meddelande i kanalen och som en länk i kalenderhändelsen, och varje inloggad medlem läser den på sitt eget språk: dokumentationen översätts per läsare, den skrivs inte en gång på det språk rummet råkade använda. Vilken medlem som helst kan redigera den, varje redigering behåller författare och revisionshistorik, och kanalen behåller sammanfattningen av varje tidigare session, så genomgången som gav v1.3 ligger ett klick från anteckningen som är v1.3. En medlems egen assistent (Claude, ChatGPT, Copilot eller Gemini, ansluten via MCP-kopplingen) söker i sammanfattningar, transkript, chattar och texten i delade filer med en enda fråga, "varför skickas laptopen fem dagar före startdatum?", och läser själva dokumentet. Det här fungerar för organisationer med AI-funktioner påslagna. Ställt bredvid tabellen ovan är skillnaden ett enkelt faktapåstående: undertexterna som de sviterna dokumenterar översätter samtalet medan det pågår; här är processen, dess genomgång och dess historik en enda post, läst av varje medlem på sitt eget språk.

De som deltar i en process är inte alltid anställda. En distributörs orderexpeditör, en löneleverantör i ett annat land, en konsult som äger en fas: en extern medlem i kanalen ansluter via e-post med ett gratiskonto och läser processen och dess historik som alla andra. En person utan konto är gäst på ett enda möte: hen ansluter till genomgången via länk, från en telefon, utan kostnad, hör den live på sitt eget språk och får ingen post efteråt. Värden tillhandahåller utrymmet och betalar, på en betald plan, bara för de medlemmar som varit aktiva de senaste 28 dagarna, alltså de som deltagit i ett möte, skrivit i en chatt eller frågat assistenten; medlemmar som blir tysta behåller sin åtkomst utan kostnad.

• Öppna en komplett sammanfattning — en verklig post, renderad av samma kod som skriver din.
• Prova livedemon — ingen registrering; tala och hör rummet översatt per lyssnare.

Processdokumentation som hantverk överlever varje verktyg: någon måste fortfarande följa tre verkliga ärenden, skriva faserna som överlämningar som en andra person kan kontrollera och gå igenom helheten med en person per roll. Det som inte behöver överleva är det andra jobbet: att för hand hålla en översatt kopia av varje version och skriva om det genomgången ändrade, på ett enda språk, åt människor som läser andra.

FAQ

Vad är processdokumentation?

Processdokumentation är den skriftliga beskrivningen av hur ett arbete rör sig genom en organisation, från händelsen som startar det till resultatet som avslutar det: faserna i ordning, rollen som äger var och en, vad som går från en roll till nästa, vad varje fas lämnar efter sig, undantagen utanför den normala vägen och vem som avgör dem, och de få siffror som ägaren bevakar. Den ligger mellan processkartan, diagrammet, och SOP:erna som beskriver hur varje fas utförs steg för steg.

Vad ska ingå i processdokumentation?

Ett huvud med ID, version, ägare, ikraftträdandedatum och nästa översynsdatum; syfte och resultat; utlösaren och sluttillståndet; omfattningen, inklusive vad processen inte täcker; rollerna, med en namngiven processägare; faserna i ordning, var och en med rollen, indata, utdata och var det registreras, nästa roll och tidsgränsen; undantag och eskalering med en beslutsfattare för varje; två eller tre mått; samt de relaterade SOP:erna, policyn den genomför och en versionshistorik.

Hur dokumenterar man en process steg för steg?

Välj en process med tydlig utlösare och tydligt sluttillstånd. Följ tre verkliga ärenden från start till slut och skriv ner vad som faktiskt hände, inklusive grenarna. Skissa faserna först, i mallen, var och en som en överlämning: roll, indata, utdata, nästa roll, tidsgräns. Lägg till undantagen som ärendena avslöjade, med vem som avgör var och en. Fyll i syfte, omfattning, roller och huvud. Gå igenom dokumentet med en person per roll, där var och en läser upp sin egen fas och bekräftar överlämningarna. Publicera det där teamet redan läser, med ägaren och översynsdatumet synliga, och lägg översynsdatumet i kalendern.

Vad är skillnaden mellan processdokumentation och en SOP?

Processdokumentation beskriver hur arbete flödar mellan roller och team (faser, överlämningar, vad varje fas lämnar efter sig) på nivån en sida per process. En SOP beskriver hur en av faserna utförs av en roll, steg för steg, ner till resultatet varje steg ger. Processdokumentet talar om var SOP:erna behövs och vem som lämnar vad till vem; en SOP talar om för en person vad hen ska göra på tisdagsmorgonen. Att skriva en SOP för en hel process som korsar flera team ger en manual som ingen öppnar; att skriva ett processdokument med SOP-detaljer ger samma sak.

Vilka är exempel på processdokumentation?

Varje återkommande flöde som korsar roller och har tydlig start och slut: introduktion av en nyanställd från undertecknat avtal till dag 30; en order från en distributör till bekräftad leverans och en faktura; en kundreklamation från mottagning till avslut; en patient från remiss till första besök; en ny produkt från godkänd brief till listad i katalogen; månadsavslut från tidrapporter till skickade fakturor. Det genomarbetade exemplet i den här guiden är introduktion av en anställd, sex faser över fyra roller, tre undantag och en historik med tre versioner, med ett kortare exempel på order till leverans efteråt.

Finns det en mall för processdokumentation i Word eller Google Docs?

Mallen i den här guiden är ren text med fetstilta etiketter, så den kan klistras in i ett Word-dokument, ett Google Doc, en wikisida, en Slack canvas eller en chattanteckning utan omformatering. Formatet spelar större roll än filen: det som håller dokumentet behöver huvudet med ägaren och översynsdatumet, utlösaren och sluttillståndet, faser skrivna som överlämningar mellan roller med en tidsgräns, en namngiven beslutsfattare för varje undantag och en versionshistorik. Och det behöver finnas där de som kör processen redan läser.

Vem ska skriva processdokumentation?

Processägaren, en namngiven person som ansvarar för hela flödet, vanligtvis chefen för det område som processen mest löper genom, tillsammans med en person från varje roll som har en fas. Ägaren håller i pennan och översynsdatumet; de som utför faserna är medförfattare, eftersom ett dokument skrivet om dem i stället för med dem beskriver processen som den är designad medan den verkliga lever i deras huvuden. En nyanländ är testaren: om hen kan hitta sin fas och de två intill på under en minut fungerar dokumentet.

Hur ofta bör processdokumentation uppdateras?

På översynsdatumet i dess huvud, vanligtvis var sjätte eller tolfte månad och oftare där processen är reglerad, och tidigare när något av fyra saker händer: en överlämning misslyckades och ingen ägde den, ett verktyg eller formulär som en fas beror på ändrades, regeln som processen genomför ändrades eller måtten rörde sig. Varje uppdatering är en ny version med en rad i historiken som säger vad som ändrades och vem som godkände det; den gamla versionen sparas, och de vars faser ändrades får veta det, med de rader som ändrats, samma dag.

Källor: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Microsofts, Googles och Slacks sidor om mötesanteckningar och mallar kontrollerades oktober 2026; Zooms sida om mötessammanfattning och sidorna om undertexter i Teams och Meet kontrollerades augusti 2026. Leverantörerna ändrar planer, funktioner och språklistor över tid; se deras sidor för aktuellt läge.