The weekly client report: one page, three questions and a decisions section that unblocks the project

According to The Bricks’ guide to report templates, many projects slip because decisions are left hanging, not because the team is slow. FDEs working on a client site will know the pattern. The model runs and the pipeline is finished, yet a whole week goes by without anyone deciding whether the agent may send emails to real customers on its own.

A weekly report is the cheapest tool for clearing that kind of blockage.

A good report answers exactly three questions: what was achieved this week, which risks are growing, and what the client needs to decide, and by when. This guide shows how to build a one-page template around those three questions, fills it in with a hypothetical example, then explains how to put the skill on your CV.

What to prepare before writing the first line

The guide follows one hypothetical scenario throughout. You are an FDE deploying an agent that classifies and drafts replies to emails for the customer service department of a logistics company. By the end you will have a reusable weekly Markdown template and a completed version for this project.

You need the list of milestones agreed with the client, your notes on the week’s work and the names of the people on the client side who have authority over each decision. If you do not yet know who decides what, treat that as the first risk to record in the report.

Step 1: ask the client what they want before you write

Simply Stakeholders, a site that specialises in stakeholder management, advises agreeing three things at the start: what information stakeholders want, how often they want it, and in what format or through which channel. At the logistics company in the example, the operations director may read only email, while the IT lead prefers Slack or Jira.

The question takes five minutes at the kickoff meeting and saves you from writing a polished report that nobody opens. Write the answers at the top of the template so the rest of the team knows them too.

Check: you have written down the recipient’s name, the channel and a fixed day of the week for sending.

Step 2: build the structure, then keep it fixed

The structure should have six sections and keep the same format every week, so the client always knows where to look. Below is a template you can use straight away. It is a condensed version, so adapt it to your project:

# Weekly report – [Project name] – Week [number], [date sent]
Overall status: GREEN / AMBER / RED — Reason: [one sentence, with evidence]

## 1. Outcomes this week
## 2. Plan for next week
## 3. Risks and issues
| Risk | Trend | Impact | Mitigation | Owner |
## 4. Decisions needed from you
| Decision | Decision-maker | Options | Deadline | If delayed |
## 5. Actions for the client team
| Action | Owner | Deadline |
## 6. Milestones
| Milestone | Planned date | Status |

A single short page is usually enough. If yours runs onto a second page, you are probably recounting work done rather than reporting outcomes.

Check: the empty template fits on one laptop screen.

Step 3: write outcomes, not activities

The rule for section 1 is short: list outcomes, not activities. If you are used to standups in the “what I did yesterday” format, this is where you are most likely to slip.

Compare two ways of writing up the same week on the email agent project:

The right-hand column answers the question the client actually cares about: “What do I have now that I did not have before?” A useful self-check is whether each line contains something the client can look at, run or sign off.

Check: no line in section 1 begins with “met”, “researched” or “explored”.

Step 4: choose colours on evidence, not on feel

The status colour must rest on evidence: whether milestones have moved, how serious the current blockers are, and whether risks are rising or falling. You can set your own rules. Green when every milestone is on schedule; amber when one milestone is at risk of slipping but a mitigation is in place.

Red when a milestone will certainly slip, or when a blocker exists that the team cannot remove on its own. Under those rules the email agent project is amber this week: the real-user trial milestone is at risk because the team still lacks access to the shipment tracking system, but it has a workaround.

The Bricks warns that marking everything green when the team knows there is a problem erodes trust and makes the report useless. Stakeholders, by contrast, value an honest amber or red, because it gives them a chance to help before things get worse.

Check: the “Reason” line beside the status colour mentions a specific milestone, blocker or risk.

Step 5: raise risks while they are still small

Clients are usually more comfortable with a problem reported early with a clear mitigation than with a last-minute surprise. That is why the risks section should include a “Trend” column, so the client can see a risk growing before it becomes an incident.

In the example, the main risk line might read: “No access yet to the shipment tracking system. Trend: rising, as we have been waiting two weeks. Impact: the agent cannot yet answer questions about order status. Mitigation: use the daily data export file for now. Owner: client IT lead.”

Do not pad this section to look busy, and do not leave it empty to look fine. Three real risks beat ten generic lines.

Check: every risk has a mitigation and a named owner.

Step 6: write the decisions section so the client can decide on the spot

Because so many projects slip on pending decisions, this is the section that keeps yours moving. Everything the client needs to do should sit in one place, each item with an owner and a deadline. Decision requests in particular must state what the decision is, who makes it, the options, the deadline and the consequence of delay.

Applied to the email agent project:

| Decision | Decision-maker | Options | Deadline | If delayed |
| Should the agent send replies directly or only draft them? | Head of customer service | A: drafts only; staff review and send. B: sends automatically for simple email types | Wednesday | The real-user trial cannot start next week |

Note the last column. Without it, the decision is easily pushed to the following week. With it, the reader sees at once what hesitation will cost the project. You can add the option the FDE team recommends, but the choice remains the client’s.

Check: the client can answer each row with a single “A” or “B”.

Step 7: send it before the meeting, not during it

Edworking advises publishing the report ahead of the weekly meeting so stakeholders read it in advance and arrive ready to decide. If the meeting is on Monday afternoon, send it on Friday afternoon or Monday morning. The meeting is then spent on section 4, not on reading section 1 aloud.

Check: after the meeting, you update the “Deadline” column or mark decisions as made, then use that same document as the starting point for next week.

Mistakes that make the report useless

The first mistake to avoid is changing the structure each week because “a lot happened this week”. The client then has to hunt for information from scratch, and the decisions get buried mid-paragraph. Just as damaging is scattering decision requests through the progress section, in the style of “it would be good if you could confirm”.

One more: keeping the status green for another week in the hope of fixing things in time. That is exactly the kind of last-minute surprise clients do not want.

Putting the skill on your CV and in interviews

Simply Stakeholders argues that regular reporting keeps the right people informed, and that systematic stakeholder management helps identify and reduce risk. When reading FDE job descriptions, look for requirements about working with stakeholders or communicating with clients, since that is where this skill counts.

On your CV, do not write “strong communication skills”. Write a line with an action and an outcome, for example: “Wrote one-page weekly client reports flagging risks and pending decisions, helping to resolve a blocker on data access”.

In interviews, be ready to describe a time you proactively moved a status to amber and what happened next.

The code you write on a client site creates value only once someone agrees to let it run. Friday’s report is where you ask for that agreement, so write it so the client can answer in a minute.