Project Status Report Template for Agencies (2026)

Quick Answer (2026): A project status report template is a one-page, repeatable summary that tells a client where their project stands this week: overall health as a single red, amber, or green rating, what shipped, what is blocked, and the one decision you need from them. For software agencies in 2026, the version that actually earns trust leads with the ask, uses fixed RAG thresholds so the color is not a mood, and takes under five minutes to fill in. Copy the template below and adapt the bracketed fields.

Most agency status reports fail for the same reason. They are a backward-looking task diary that buries the one thing the client needs to act on under a list of everything the team touched. The client skims it, understands nothing about risk, and either stops reading the weekly update or panics at the first surprise. A good status report is not a record of activity. It is a decision instrument.

This template inverts the usual order. It leads with the decision you need, states overall health as a color with rules behind it, and keeps the evidence short. It is built for fixed-price AI and software engagements, where scope drift and a late client dependency are the two failures that quietly eat your margin.

What a project status report actually does

A weekly status report has three jobs, in this order:

1. Surface the decisions. If you need the client to approve a change, unblock an SME, or accept a slip, that goes at the top, not on page two.
2. Set expectations before they are broken. Amber this week is cheap. A red surprise at the deadline costs you the relationship and often the final invoice.
3. Create a paper trail. When a fixed-price project ends in a dispute about scope, the weekly reports are the record that shows what was flagged, when, and who owned it.

Formal project communication management, as the Project Management Institute frames it, exists to get the right information to the right stakeholder at the right time. For an agency, "the right information" is almost always a decision the client has to make, plus enough context to make it. Everything else is noise you are adding because it feels like proof of work.

The one-page format: seven fields

Keep it to a single screen. Seven fields cover every software engagement without turning the report into homework.

1. The ask. The decision or action you need from the client this period. One sentence. If there is none, say so explicitly.
2. Overall status. Green, amber, or red, chosen by the rules in the next section, not by feel.
3. Headline. One or two sentences on where the project stands.
4. Progress this period. What shipped or completed. Outcomes, not tickets.
5. Planned next period. What the team will deliver next.
6. Risks and blockers. Each with an owner, a status, and a rated impact.
7. Scope and budget. Scope changes, budget consumed against the fixed price, and timeline health.

The order matters. Leading with the ask is the single change that separates a report clients read from one they archive unread. It is also a counter to the instinct most delivery leads have, which is to open with a proud list of completed work.

RAG rules: make the color mean something

A red, amber, green rating is only useful if the client and the team agree on what each color means. Publish the thresholds once, at kickoff, and never move them mid-project. Here is a default set for fixed-price software work in 2026.

The value of fixed thresholds is that amber stops being an argument. When a client SME is four days late signing off on a knowledge base, the project is amber by rule, and the report says so without anyone having to defend a judgment call. Set these thresholds in the same conversation where you agree the plan, ideally during the project kickoff meeting.

The copy-paste template

Paste this into your weekly update, a shared doc, or your project tool of choice, and fill the bracketed fields. Keep it plain text so it survives copy-paste into email, a client portal, or a PDF.

PROJECT STATUS REPORT

Project:           [Client / project name]
Reporting period:  [Week of Month D, YYYY]
Prepared by:       [Your name, agency]
Overall status:    [GREEN / AMBER / RED]

1. THE ASK (decision or action needed from you this week)
   [One sentence. If none: "No decision needed this week."]

2. HEADLINE
   [One or two sentences on where the project stands.]

3. PROGRESS THIS PERIOD
   - [Shipped or completed outcome]
   - [Shipped or completed outcome]

4. PLANNED NEXT PERIOD
   - [Outcome the team will deliver]
   - [Outcome the team will deliver]

5. RISKS AND BLOCKERS
   - [Risk or blocker] | Owner: [name] | Status: [open / mitigating] | Impact: [GREEN/AMBER/RED]

6. SCOPE AND BUDGET
   Scope changes this period: [none / see change request #]
   Budget consumed:           [X% of fixed price, or X of Y hours]
   Timeline:                  [on track / N days behind, recovery plan below]

7. NOTES
   [Anything the client should know but does not need to act on.]

If your team already lives in Asana or Basecamp, pull the raw progress data from there, but write the client-facing summary by hand. An auto-generated activity dump is exactly the backward-looking diary this format is designed to replace.

A worked example: week 4 of an 8-week fixed-price AI build

Numbers make the format concrete. Here is a real-shaped status report for a $32,000 fixed-price engagement: building an AI support assistant for a mid-market SaaS client, eight weeks, delivered by a two-person team.

PROJECT STATUS REPORT

Project:           Acme SaaS - AI support assistant
Reporting period:  Week of July 13, 2026 (week 4 of 8)
Prepared by:       Delivery lead, DevShopVault
Overall status:    AMBER

1. THE ASK
   Approve adding a retrieval step over your help-center content
   (see change request #2). It improves answer accuracy and adds 3 days.

2. HEADLINE
   Core assistant is answering test questions end to end. We are amber
   because knowledge-base sign-off from your side is 5 days late, which
   blocks the accuracy testing scheduled for week 5.

3. PROGRESS THIS PERIOD
   - Assistant handles the top 20 support intents in staging
   - Conversation logging and eval harness live
   - Draft retrieval design shared for review

4. PLANNED NEXT PERIOD
   - Accuracy testing against your real tickets (needs KB sign-off)
   - Wire the approved retrieval step, if change request #2 is accepted

5. RISKS AND BLOCKERS
   - KB sign-off 5 days late | Owner: Acme (Priya) | Status: open | Impact: AMBER

6. SCOPE AND BUDGET
   Scope changes this period: change request #2 pending (retrieval layer)
   Budget consumed:           52% of the $32,000 fixed price at week 4 (on plan)
   Timeline:                  on track if KB sign-off lands this week

7. NOTES
   Eval harness will let you re-run accuracy checks yourself after handoff.

Read that report as a busy client and notice what you get in ten seconds: there is a decision to make, the project is recoverable, and the reason it is amber is a dependency you own, not a team failure. Budget consumed at 52% in week 4 is exactly on plan for a linear burn, so money is not the concern. The retrieval change is a scope decision, which is why it is routed through a formal change request rather than absorbed silently. That last point protects your fixed price.

Cadence and delivery

Weekly is the right default for engagements of four weeks or more. Send it the same day and time every week, before your standing call rather than during it, so the meeting is spent on the ask and not on reading. For engagements under four weeks, twice weekly keeps a short project from drifting for half its life before anyone notices.

If a project goes red, the status report is not enough on its own. Pair it with a short call the same day. Red on paper with no human follow-up reads as either a threat or an excuse, and neither builds trust.

When a slip traces back to your own team being overcommitted rather than a client dependency, the honest fix is upstream of the report. Look at whether you took on the work with realistic headroom in the first place, which is a capacity planning question, not a reporting one.

Five things that quietly kill a status report

• Burying the ask. If the client has to hunt for the decision, they will miss it, and you will own the consequence.
• A color with no rule. Amber that means "the delivery lead is nervous" invites debate. Amber that means "one client blocker is open" ends it.
• Listing tickets instead of outcomes. "Closed JIRA-412" tells a client nothing. "Assistant now handles refund questions" tells them everything.
• Hiding bad news until it is unrecoverable. The whole point of amber is to spend a cheap warning now instead of an expensive surprise later.
• Sending it inconsistently. A report that arrives whenever the team remembers trains the client to distrust the schedule as much as the status.

If you take one thing from this

Lead every status report with the decision you need from the client, and make the color a rule, not a feeling. A status report that opens with the ask and defines its own thresholds turns your weekly update from a task diary the client ignores into the instrument that keeps a fixed-price project profitable.