Mall för projektstatusrapport: veckoformat, exempel — och hur rapporten sammanställer sig själv av mötessammanfattningarna (2026)

En projektstatusrapport är en kort sida i fast format som berättar för dem som står utanför det dagliga arbetet var projektet befinner sig: enligt plan eller inte, vad som har ändrats sedan förra rapporten, vad som kan gå fel och vad läsaren ombeds besluta. Den skrivs med jämna mellanrum — varje vecka för de flesta projekt — och är samma sida varje gång, så att läsaren jämför den här veckan med förra veckan i stället för att läsa allt från början.

Den här guiden tar först hantverket — formatet, en mall du kan kopiera, ett ifyllt exempel och en kortare veckoversion för en teamledare som rapporterar uppåt. Därefter kommer mekaniken: när en rapport räcker och när ett statusmöte ändå är värt att kalla till, var rapporten skrivs i de verktyg ditt team redan använder och vad som händer mellan mötena och sidan. Rapportens svåraste del är nämligen inte själva skrivandet. Det är halvtimmen innan, när ledaren går igenom en veckas samtal och chattar för att ta reda på vad som faktiskt kom överens.

Vad en projektstatusrapport är — och vad den inte är

Fyra dokument kretsar kring ett projekt, och rapporten är det som oftast förväxlas med de andra:

Mötessammanfattningen gäller ett enskilt möte; rapporten gäller veckan över alla möten. En stand-up lyfter hinder till de som kan röja dem; rapporten talar om för någon längre bort om hindren hotar datumet. Beslutsloggen bevarar varför; rapporten säger bara att ett beslut har fattats eller fortfarande behövs. Om rapporten är svår att skriva ligger orsaken nästan alltid uppströms: veckans möten lämnade inga spår av sina resultat, så ledaren rekonstruerar dem ur minnet på fredagseftermiddagen.

Veckoformatet: sex block, en sida

En rapport som läses varje vecka måste rymmas på en skärm och behålla samma form. Sex block, i den här ordningen:

1. Rubrikrad. Projekt, rapporteringsperiod, författare och datum för nästa rapport. Läsarna letar efter perioden först — en rapport utan period är en sida med påståenden utan något "sedan när".
2. Övergripande status på en rad. Grön, gul eller röd — eller enligt plan, i riskzonen, utanför plan — plus en mening som säger varför. Färgen är en sammanfattning av blocken nedanför, inte en känsla; om riskblocket säger att en leverantör är två veckor sen kan raden inte säga grönt.
3. Framsteg sedan förra rapporten. Tre till sex rader om vad som blev klart, var och en som ett resultat snarare än en aktivitet. "Kassaflödet är under granskning hos kunden" är ett faktum; "arbetade med kassan" är det inte.
4. Nästa period. Vad teamet åtar sig att göra klart före nästa rapport, var och en med en ansvarig. Det är mot det här blocket som nästa veckas framstegsblock kontrolleras.
5. Risker, problem och beslut som behövs. En risk är något som kan hända; ett problem är något som har hänt. Varje rad: vad, effekten på datum eller budget, den ansvarige och vad läsaren ombeds göra — inklusive "ingenting, för kännedom". Beslut som behövs får en egen rad med det datum då projektet behöver svaret.
6. Öppna åtgärder. Varje åtgärd som fortfarande är öppen från något möte under perioden, med ansvarig och förfallodatum, och en markering på dem som är försenade. Det här är blocket som de flesta rapporter hoppar över, och det som läsaren använder för att bedöma om färgen i block 2 är ärlig.

Tre saker ska lämnas utanför: dialog (vem som sa vad), aktivitetsloggar (timmar, antal samtal) och allt som läsaren inte kan agera på. Rapporten är till för någon som ägnar den fyra minuter. Varje rad ska klara frågan "vad skulle läsaren göra annorlunda om hen visste det här?"

Mall för projektstatusrapport

Kopiera in den här i ett dokument, ett kanalmeddelande eller en canvas. Hakparenteser är platshållare.

[Projekt] — statusrapport för [period, t.ex. 20–24 oktober]
Författare: [namn] · Skickad: [datum] · Nästa rapport: [datum]
Övergripande: [enligt plan / i riskzonen / utanför plan] — [en mening som säger varför]

Klart sedan förra rapporten
– [Resultat, som ett faktum] — [ansvarig]
– [Resultat] — [ansvarig]
– [Resultat] — [ansvarig]

Nästa period (till [datum för nästa rapport])
– [Leverans] — [ansvarig]
– [Leverans] — [ansvarig]

Risker och problem
– [Risk eller problem] — effekt: [datum / budget / omfattning] — ansvarig: [namn] — begäran: [beslut som behövs senast datum / för kännedom]

Beslut som behövs
– [Fråga, med alternativen på bordet] — behövs senast [datum] — från [namn]

Öppna åtgärder
– [Uppgift] — [ansvarig] — förfaller [datum] — [öppen / försenad sedan datum]
– [Uppgift] — [ansvarig] — förfaller [datum] — [öppen]

Ordningen är genomtänkt. En sponsor som bara läser de tre första raderna får färgen och skälet; den som läser till slutet får åtgärderna som förklarar färgen. Behåll rubrikerna oförändrade från vecka till vecka — formatets värde ligger i jämförelsen.

Exempel: en ifylld veckorapport

Ett litet mjukvaruprojekt, ett team med två språk och en kund som läser rapporten varje måndag:

Orderportal v2 — statusrapport för 20–24 oktober
Författare: Mateusz · Skickad: 24 oktober · Nästa rapport: 31 oktober
Övergripande: i riskzonen — betalleverantörens sandlåda kom fyra dagar för sent; lanseringsdatumet håller bara om integrationstestet klaras senast den 29 oktober.

Klart sedan förra rapporten
– Kassaflödet är under granskning hos kunden; två kommentarer är öppna — Ana
– Produktimport från ERP-systemet körs nattligen i staging — Priya
– Spanska och rumänska gränssnittstexter klara; franska på 80 % — Luca

Nästa period (till 31 oktober)
– Betalintegrationstest i leverantörens sandlåda — Priya
– Kundens godkännande av kassan — Ana
– Franska texter klara, alla tre språken granskade — Luca

Risker och problem
– Försenad betalningssandlåda (problem) — effekt: lansering 7 november håller bara om testet klaras senast 29 oktober; annars 14 november — ansvarig: Priya — begäran: för kännedom, beslut nedan
– Kundens granskningstid (risk) — effekt: varje omgång tar 3 dagar; en tredje omgång flyttar godkännandet förbi testfönstret — ansvarig: Ana — begäran: kunden samlar kommentarerna i en omgång

Beslut som behövs
– Om testet misslyckas den 29 oktober: lansera 14 november med betalningar, eller 7 november med enbart fakturabetalning och kortbetalningar senare — behövs senast 30 oktober — från kunden

Öppna åtgärder
– Skicka IP-tillåtelselistan till leverantören — Priya — förfaller 21 oktober — försenad sedan 21 oktober
– Bekräfta driftsättningsfönstret med hostingpartnern — Mateusz — förfaller 28 oktober — öppen
– Svara på de två kommentarerna om kassan — Ana — förfaller 27 oktober — öppen

Lägg märke till vad exemplet inte säger: hur många möten som hölls, vem som talade, hur många timmar som gick åt. Läsaren får veta på en rad att datumet är i riskzonen och i ett block vad hen ombeds besluta.

Veckorapportmall för en teamledare

En teamledares veckorapport till sin egen chef är en kortare kusin till projektrapporten. Läsaren är en enda person, oftast med mindre än två minuter, och frågorna är tre: håller teamet sina åtaganden, vad står i vägen och vad behöver du från mig. Fyra block ryms i ett chattmeddelande:

Team [namn] — vecka [datum]
Status: [enligt plan / i riskzonen] — [en rad]
Levererat: [två eller tre resultat, vart och ett med ett namn]
I vägen: [ett eller två hinder, vart och ett med vem som kan röja det]
Behövs från dig: [ett beslut eller en resurs, med ett datum] — eller "ingenting den här veckan"

Två regler som gör rapporten läsbar över månader. För det första är "Behövs från dig" aldrig tomt av misstag: skriv "ingenting den här veckan" så att chefen vet att tystnaden är avsiktlig. För det andra innehåller "Levererat" människors namn — en veckorapport är också stället där en ledare gör teamets arbete synligt för någon som inte ser det dagligen. Om teamet redan har en daglig stand-up med namngivna hinder är "I vägen" en kopia av dem som fortfarande står kvar på fredagen.

Veckorapporten ersätter veckans statusmöte för det mesta av det mötet bar — informationen. Vad den inte kan ersätta behandlas härnäst.

När ett statusmöte fortfarande behövs

Ett statusmöte är rapportens levande form: var och en berättar för ledaren eller sponsorn hur läget är, i ett rum, till allas kostnad. När en skriftlig rapport väl finns är mötet motiverat bara när sidan inte kan göra jobbet. Fyra fall:

• Ett beslut med en avvägning. Rapporten kan redovisa alternativen; den kan inte förhandla om dem. När "Beslut som behövs" har en post vars svar beror på vad två intressenter är beredda att ge upp slår trettio minuter med båda i rummet två veckors svara-alla-mejl.
• Ett datum flyttas. En försening accepteras sällan från en sida. Samtalet om vad som flyttas med den — omfattning, budget, ett annat projekts start — är ett möte, med rapporten som förhandsläsning.
• En risk har passerat sin tröskel. Den vecka en risk blir ett problem behöver de som äger konsekvenserna höra det från ledaren och kunna ställa frågor, inte läsa det på måndagen.
• En ny intressent. Den som inte har läst de föregående sex rapporterna behöver ett enda tillfälle för att få en bild av projektet; därefter räcker sidan.

Ett statusmöte är inte till för att läsa upp rapporten. Om varje punkt på dagordningen är "uppdatering från X", ställ in mötet och skicka sidan; guiden om mötesrytm går igenom vilka återkommande möten som förtjänar sin plats. När mötet hålls, kör det utifrån rapporten — risk- och beslutsblocken är dagordningen, och ett effektivt möte slutar med att de punkterna är markerade som beslutade, öppna eller uppskjutna. Med intressenter som talar olika språk har rummet tre alternativ för själva mötet: en mänsklig tolk — guiden om Zoom-tolk visar hur det ställs in — plattformens egna undertexter, eller ett utrymme som översätter för varje deltagare; rapporten, som skrivs en gång, är en separat fråga.

Var rapporten skrivs i de verktyg du redan använder

Varje större plattform lämnar något efter ett möte som en statusrapport kan byggas på, och varje plattform stannar på olika ställen. Endast dokumenterat beteende, hämtat från leverantörernas egna sidor, med den månad då varje sida kontrollerades:

Två saker är desamma överallt. Det ett möte lämnar efter sig är ett dokument per möte, på det enda språk som användes i rummet; och om förra veckans nästa steg blev gjorda är inget dokumentet vet — ledaren går och kontrollerar innan hen skriver "klart". Plattformarnas liveundertexter — det som Teams och Google Meet visar på skärmen under ett samtal — ändrar inte dokumentet efteråt. Anteckningsverktyg är samma kategori ett steg längre: de som jämförs i Otter.ai alternatives skriver en sammanfattning per möte, och en rapport som spänner över en månads möten är fortfarande en separat sida.

Så sammanställer sig rapporten av mötessammanfattningarna

InterMIND är ett utrymme för kommunikation där ett projekt lever i en kanal, så rapportens underlag har ett givet hem. Varje möte i kanalen avslutas med en mötessammanfattning — en sammanfattning, besluten, åtgärdspunkterna med ansvariga och datum — skriven utifrån själva mötet och levererad med e-post, som ett meddelande i kanalen och som en länk i kalenderhändelsen. Varje inloggad medlem läser den på sitt eget språk: protokollet översätts per läsare, inte skrivet en gång på det språk rummet råkade använda, och detsamma gäller kanalens chatt runt omkring, där varje medlem skriver på sitt eget språk. Vilken medlem som helst kan redigera mötessammanfattningen, varje ändring behåller författare och revisionshistorik, och kanalen sparar mötessammanfattningen från varje tidigare möte — så "klart sedan förra rapporten" blir en bläddring genom veckans mötessammanfattningar i stället för en rekonstruktion.

Åtgärdspunkterna bär sin status med sig. En punkt visas som att göra, klar eller inte klar med ett skäl, och i en organisation med teamstatussidor aktiverade bedöms de öppna punkterna från tidigare möten när nästa mötessammanfattning skrivs: en punkt som någon rapporterade som färdig markeras klar, en punkt som diskuterades men inte blev klar markeras inte klar med skälet formulerat med mötets egna ord, och en punkt som ingen tog upp förblir öppen. Det är mallens block "öppna åtgärder", skött av mötena i stället för av ledaren.

Teamstatussidorna är varifrån resten av rapporten kommer. En sida över de senaste 7, 28 eller 90 dagarna listar organisationens uppgifter, problem, det som är viktigt och brådskande samt de pengar som står på spel, och varje rad bär det ordagranna citat ur mötessammanfattningen som den vilar på; en uppgift ligger kvar tills någon stänger den, och efter fyra veckor utan rörelse markeras den som avstannad. Ledaren skriver trendraden och färgen — bedömningen — över en sida som mötena redan har fyllt i. Samma sida kan läsas via en ansluten assistent: en ledare som arbetar i Claude, ChatGPT, Copilot eller Gemini ber om veckans öppna uppgifter och problem och får raderna med sina citat. Teamstatussidor är en förhandsfunktion i betalda planer: en organisations administratör aktiverar dem under Inställningar → Avancerat efter att ha godkänt alfavillkoren (sidan Preview features beskriver var och en).

Där rapporten ska landa i ett affärssystem lägger värden till en kopia av mötessammanfattningen till valfri adress — en CRM- eller projektverktygs inkommande brevlåda — och varje mötessammanfattning från mötet eller kanalen skickas också dit efter en engångsbekräftelse av adressen; mekaniken finns i en kopia av varje mötessammanfattning i ditt CRM, via e-post, och samma mötessammanfattning kommer som en webhook eller en Zapier-trigger för team som själva lägger in den i ett projektverktyg.

En kundintressent som ska se mötessammanfattningarna bjuds in till kanalen via e-post och ansluter med ett gratiskonto, och läser på sitt eget språk; externa deltagare i en kanal kostar värden ingenting. En gäst vid ett enskilt möte ansluter via länk, utan konto och utan kostnad — från en telefon, i webbläsaren — och hör mötet live på sitt eget språk. Efteråt finns ingen journal för en gäst — kontot är gratis, och det är kontot som gör journalen nåbar. Värden tillhandahåller utrymmet och betalar, i en betald plan, bara för medlemmar som varit aktiva de senaste 28 dagarna; medlemmar som blir tysta behåller sin åtkomst utan kostnad.

• Öppna en komplett mötessammanfattning — en verklig journal, renderad av samma kod som skriver din.
• Testa livedemon — ingen registrering; tala, och hör rummet översättas för varje lyssnare.

Rapporten som hantverk överlever varje verktyg: någon måste fortfarande säga om projektet är enligt plan och varför. Det som inte behöver överleva är fredagens halvtimme — att gå igenom en veckas samtal, på ett enda språk, för att ta reda på vad som kom överens och om någon gjorde det.

FAQ

Vad är en projektstatusrapport?

En kort sida i fast format som skickas med jämna mellanrum — vanligtvis varje vecka — och som berättar för människor utanför det dagliga arbetet var ett projekt befinner sig: en övergripande status på en rad med skälet, vad som blev klart sedan förra rapporten, vad som är planerat före nästa, riskerna och problemen med deras effekt på datum eller budget, de beslut läsaren ombeds fatta och de åtgärder som fortfarande är öppna med ansvariga och förfallodatum. Det är samma sida varje gång, så att läsaren jämför veckor i stället för att läsa från början.

Vad bör en veckorapport innehålla?

Sex block: en rubrikrad med rapporteringsperioden; en rad övergripande status med skälet; framsteg sedan förra rapporten som resultat, inte aktiviteter; åtagandena för nästa period med ansvariga; risker, problem och beslut som behövs, var och en med sin effekt och en begäran; samt varje öppen åtgärd med ansvarig och förfallodatum, med de försenade markerade. Lämna utanför dialog, timmar och allt som läsaren inte kan agera på.

Hur skriver man en projektstatusrapport?

Utgå från den förra rapporten: dess block "nästa period" är den här veckans checklista, och dess öppna åtgärder är antingen klara eller fortfarande öppna. Gå sedan igenom veckans mötessammanfattningar för vad som beslutades och vad som tillkom. Skriv statusraden sist, efter riskblocket, så att färgen stämmer med fakta. Skicka rapporten samma dag varje vecka, till samma lista, och behåll rubrikerna oförändrade från en rapport till nästa.

Vad är skillnaden mellan en statusrapport och ett statusmöte?

En statusrapport skrivs och läses asynkront; ett statusmöte är samma information levererad live, till priset av allas tid i rummet. När en rapport finns är ett möte motiverat när sidan inte kan göra jobbet: ett beslut med en avvägning mellan intressenter, ett datum som flyttas, en risk som just har blivit ett problem eller en ny intressent som behöver få projektets form förklarad en gång. Ett möte vars dagordning är "uppdatering från var och en" är en rapport som läses upp.

Skiljer sig en veckorapportmall för en teamledare från en projektstatusrapport?

Den är kortare och riktad till en person. En teamledares veckorapport till sin chef besvarar tre frågor i fyra block — status på en rad, vad teamet levererade med namn, vad som står i vägen och vem som kan röja det, samt vad som behövs från chefen och till när — och ryms i ett chattmeddelande. En projektstatusrapport är längre, spänner över en period och en grupp intressenter och bär risker, beslut och öppna åtgärder över alla projektets möten.

Hur ofta bör en projektstatusrapport skickas?

Varje vecka för de flesta projekt: tillräckligt ofta för att en försening fångas inom en vecka, tillräckligt sällan för att varje rapport har något nytt. Varannan vecka passar långa, stadiga projekt med få beslut; daglig rapportering hör hemma i en lanseringsvecka eller en incident och är ett annat, kortare dokument. Oavsett frekvens ska dagen och mottagarlistan inte ändras — en rapport som kommer en annan dag varje vecka läses inte som en serie.

Bör kunden få statusrapporten?

Ja, om kunden betalar för projektet och ett beslut i rapporten är kundens att fatta — blocket "beslut som behövs" är skrivet för dem. Skriv helst en rapport för alla, i stället för en kundversion och en intern; en rapport med två versioner glider isär, och den interna blir den verkliga. Det som hålls utanför en delad rapport är teamets interna detaljer — individuella prestationer, uppskattningar under förhandling — som hör hemma i ledarens egna anteckningar.

Källor: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap 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" suggests next steps; Slack — Meeting agenda template (canvas). Microsofts anteckningssidor, Google Meets anteckningssidor och Slacks sidor kontrollerades oktober 2026; Googles tillkännagivande om nästa steg kontrollerades september 2026; Microsofts sida om sammanfattningar och Zooms sida om mötessammanfattningar kontrollerades augusti 2026. Leverantörer ändrar planer, funktioner och språklistor över tid; kontrollera deras sidor för aktuellt läge.