TL;DR: A client update generator turns a week of messy notes into a status email that answers three questions: are we on track, what do you need from me, and what changed since last week. Below are 27 free prompts and templates, one per situation, each instructed to use only your facts and mark everything else NOT PROVIDED.
What should a client update generator actually produce?
Not a diary. That is the whole argument of this page, and it is where almost every status-update template goes wrong.
The standard shape is a list of activity in the order it happened. Monday we did this, Wednesday we did that, Thursday we had a call. It feels responsible to write, because it proves you were busy. It is close to useless to read, because it makes the client derive the only three things they wanted: are we on track, do you need anything from me, and what has changed since the last one of these.
So the structure inverts. Status first, ask second, detail last. Everything below uses this skeleton.
Subject: [PROJECT] — [ON TRACK / AT RISK / DELAYED / BLOCKED] — week of [DATE]
STATUS: [ONE OF THE FOUR WORDS ABOVE]. [DELIVERABLE] still lands [DATE].
CHANGED SINCE LAST WEEK
- [FACT]
- [FACT]
NEED FROM YOU
- [ONE ASK] by [DATE]. [WHAT IT UNBLOCKS.]
NEXT UPDATE: [DATE]
---
Detail, for whoever wants it:
Done: [ITEMS]
In progress: [ITEMS]
Not started: [ITEMS]
Six lines above the divider. A client reading on a phone in a lift gets the entire decision. The person who wants the detail scrolls.
Here is the generator that converts a week of notes into that shape. Paste your raw notes at the bottom, however scrappy they are.
You turn a contractor's messy weekly notes into a client status email.
RULES (do not skip)
- Use ONLY the facts in NOTES. Add nothing.
- Any field I left blank, print literally as: NOT PROVIDED
- Do not characterise progress I have not described. If my note says
"started API work" do not write "API work is progressing well".
- Do not state any date I have not given you. If a date is needed and
I did not supply one, write: NOT PROVIDED — I need a date from you.
- Ban: excited, thrilled, just circling back, touching base, quick one,
wanted to check in, as per my last email.
- Output the skeleton exactly. No preamble, no sign-off flourish.
SKELETON
Subject: [PROJECT] — [STATUS WORD] — week of [DATE]
STATUS: one line. On track / At risk / Delayed / Blocked, then the
delivery date and whether it moved.
CHANGED SINCE LAST WEEK: 2-4 bullets, each a fact from NOTES.
NEED FROM YOU: 0-2 bullets. Each has an owner, a date, and what it
unblocks. If NOTES contains no ask, write "Nothing this week."
NEXT UPDATE: the date.
Then a divider, then Done / In progress / Not started, from NOTES only.
CONTEXT
Project: [NAME]
Client reads: [ROLE — e.g. founder, marketing lead, IT manager]
Delivery date currently agreed: [DATE]
Tone: [PLAIN AND SHORT / WARMER / MORE FORMAL]
NOTES
[PASTE EVERYTHING. Bullet fragments, half sentences, Slack copy-paste.]
And the subject line on its own, because it is the part most people leave as "Weekly update":
Write 5 subject lines for the status email below. Each must contain the
project name and one status word from: On track, At risk, Delayed,
Blocked. No adjectives, no teasing, no questions. Under 60 characters.
Use only the status word justified by the email. If the email does not
support a status word, say so instead of picking one.
EMAIL
[PASTE]
Why does the generated update always sound better than your week was?
Because the model is built to smooth. That is the single biggest risk in using AI for status reporting, and it is worth more of your attention than the wording of any template here.
Feed a language model the note "did not start the migration" and ask for a client-facing update, and you will frequently get "the migration is progressing". Feed it a blank field and it fills the blank, because a fluent paragraph with a hole in it is exactly what its training pushes it away from. Give it three bullets about a thin week and it will find a way to make the week sound proportionate to the invoice.
None of that is lying in the model's terms. It is doing register conversion: rough internal note becomes polished client prose, and polish carries optimism as a side effect. The problem is that a status email is not marketing copy. It is a document your client may forward, quote in a meeting, or hold up in six weeks when the date is missed.
The fourth guard is about dates, and it deserves its own line: never send a date the model produced. A generated "we expect to deliver Friday" is a commitment made by software, on your behalf, to someone who will hold you to it. The model has no idea what is left in the work. Every template below marks dates as inputs you supply, and the red-team prompt at the end exists specifically to catch a date that crept in.
Before I send this, check it against my notes.
List, as a table:
1. Every factual claim in the DRAFT.
2. Whether it appears in NOTES: yes / no / partially.
3. Every date in the DRAFT and whether I supplied it.
4. Every evaluative word (well, good, strong, solid, nearly, almost,
on schedule, minor) and whether NOTES justifies it.
Then list anything in the DRAFT I did not give you. Do not fix it.
I will decide.
NOTES
[PASTE]
DRAFT
[PASTE]
Run that once and you will see how much a model adds unprompted. It is the most useful sixty seconds on this page.
Which situation are you actually in this week?
The status email is a different email each week, and template libraries that offer one shape are answering the easy case only.
| The week you had | What the client needs first | The trap |
|---|---|---|
| Routine, things shipped | Status word, then the two things that moved | Padding it to look like more work |
| Nothing visible shipped | Why, and whether the date moved | Dressing an empty week in a full week's language |
| A deadline slipped | The new date, in line one | Burying it under three paragraphs of context |
| Scope changed or they asked for more | What it costs in time or money, before you agree | Saying yes in the update and pricing it later |
| You are blocked on them | The one thing, the date, what it stops | A polite ask so soft they miss that it is urgent |
| Budget or hours running out | Hours used, hours left, the decision needed | Raising it at 100% instead of 70% |
| You made a mistake | What broke, what you did, what stops it recurring | Passive voice and a search for a co-owner |
| Project ending | What they have, where it lives, who to call | Ending on a pitch instead of a handover |
| You went quiet | The gap, then the real current state | Three apologies and a fake reason |
The two hard ones are the two most people search for, and they are hard for the same reason: the writer is avoiding the email, not struggling to word it. A template helps disproportionately there.
The routine good week
The easiest case, and the one where restraint pays. A good week does not need selling. Two facts and a date are more convincing than six bullets of atomised activity.
Subject: [PROJECT] — On track — week of [DATE]
STATUS: On track. [DELIVERABLE] still lands [DATE].
CHANGED SINCE LAST WEEK
- [THING THAT SHIPPED, and where they can see it: LINK]
- [THING THAT SHIPPED, and where they can see it: LINK]
NEED FROM YOU
Nothing this week.
NEXT UPDATE: [DATE]
---
Done: [ITEMS]
In progress: [ITEMS]
Not started: [ITEMS]
Generate a routine weekly update. STATUS is On track.
RULES: use only FACTS below; print NOT PROVIDED for anything blank; do
not characterise progress I have not described; do not invent dates.
Additional rule for this one: do NOT pad. If FACTS contains two
completed items, the email has two bullets. Never split one item into
several to make the week look bigger.
FACTS
Project: [NAME]
Delivery date: [DATE] (unchanged)
Completed this week: [ITEM] — visible at [LINK OR "no link"]
Completed this week: [ITEM] — visible at [LINK OR "no link"]
In progress: [ITEM]
Not started: [ITEM]
Anything I need from the client: [ASK, or "nothing"]
Next update: [DATE]
What do you send when nothing visible shipped?
Lead with it. The first line says nothing shipped, the second says why, the third says what it means for the date. That ordering is the entire craft of this email.
The instinct runs the other way. A thin week produces a longer email, not a shorter one, because the writer is padding to reach a volume that feels proportionate to the fee. The client reads six bullets, cannot find a deliverable in any of them, and draws the conclusion you were trying to prevent, only now with the added information that you tried to obscure it.
There are three genuinely different empty weeks and they need different emails.
The week was spent on invisible work. Research, data cleaning, environment setup, reading someone else's undocumented code. Real work, no surface. Name the work, name what it unblocks, and give the date it becomes visible.
Subject: [PROJECT] — On track — week of [DATE] — no visible output
STATUS: On track. Nothing shipped this week that you can click.
[DELIVERABLE] still lands [DATE].
WHY
This week went to [INVISIBLE WORK: e.g. mapping the legacy schema].
It has no screen attached. It is what makes [NEXT DELIVERABLE]
possible, and without it that work is [CONSEQUENCE: e.g. guesswork].
WHAT YOU WILL SEE, AND WHEN
[FIRST VISIBLE THING] on [DATE].
NEED FROM YOU
[ASK, or "Nothing this week."]
NEXT UPDATE: [DATE]
---
Done: [ITEMS]
In progress: [ITEMS]
Not started: [ITEMS]
The week was spent waiting. A third party, an approval, a review, an environment nobody could give you access to. The client may be able to move it, so this email is half status and half escalation.
Subject: [PROJECT] — At risk — week of [DATE] — waiting on [PARTY]
STATUS: At risk. Little movement this week. [DELIVERABLE] is still
[DATE], and stays [DATE] only if [DEPENDENCY] lands by [DATE].
WHAT WE WERE WAITING ON
[DEPENDENCY] from [PARTY]. Requested [DATE]. Chased [DATE], [DATE].
WHAT WE DID INSTEAD
[WORK BROUGHT FORWARD, or "Reduced hours this week — see below."]
NEED FROM YOU
[ESCALATION: e.g. an introduction to whoever owns this at PARTY]
by [DATE].
IF IT DOES NOT LAND BY [DATE]
[DELIVERABLE] moves to approximately [DATE YOU SUPPLY].
NEXT UPDATE: [DATE]
The week genuinely did not happen. Illness, a fire on another account, capacity you misjudged. This one is short and does not editorialise. It is also the one where a language model will most reliably rescue you into a sentence you should not send.
Generate a "no visible progress" update.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described; do not invent dates.
CRITICAL for this template: do not soften, and do not reframe an empty
week as progress. If FACTS lists no completed items, the email says so
in the first line. Do not write "laid the groundwork", "made headway",
"good progress behind the scenes" or any equivalent unless those exact
words appear in FACTS. Do not manufacture an upside.
FACTS
Project: [NAME]
Completed this week: [NOTHING / LIST]
Reason: [INVISIBLE WORK / WAITING ON [PARTY] / CAPACITY]
Reason detail I am willing to share: [ONE LINE, or "none"]
Delivery date: [DATE] — has it moved: [NO / YES, to DATE]
First visible output and when: [ITEM, DATE]
Ask of the client: [ASK, or "none"]
Next update: [DATE]
How do you tell a client a deadline has slipped?
New date, cause, mitigation. First three lines. Then everything else.
That is not a stylistic preference. A delay is a fact the client has to act on: they have their own launch, their own boss, their own dependent bookings. The cost of the delay is largely fixed by the time you write. The cost of finding out late is not, and it compounds every day you sit on it. Trust rarely breaks over a slipped date. It breaks over the two cheerful updates you sent after you already knew.
So the rule is: send it the day you know. Not the day the original date arrives, and not once you have a recovery plan, because a plan is nice and the date is urgent.
Subject: [PROJECT] — Delayed — [DELIVERABLE] moves to [NEW DATE]
[DELIVERABLE] will not make [ORIGINAL DATE]. The new date is
[NEW DATE].
Cause: [ONE SENTENCE, PLAIN, NO PASSIVE VOICE].
What I have changed so that it holds: [MITIGATION — the concrete
thing, e.g. "cut X from this phase", "brought in Y for the week",
"reordered so Z is not blocked by this"].
WHAT THIS DOES NOT AFFECT
[DELIVERABLE] on [DATE] is unchanged.
[DELIVERABLE] on [DATE] is unchanged.
NEED FROM YOU
[DECISION OR ASK, if any] by [DATE].
[OR: "Nothing. I wanted you to know today rather than on [ORIGINAL DATE]."]
Happy to get on a call today or tomorrow if it is easier.
NEXT UPDATE: [DATE]
Two details in that template do most of the work. "What this does not affect" tells a worried reader how far the damage travels, which is the question they are actually asking. And the offer of a call signals that you are not hiding, without demanding a meeting from someone who may just want the facts.
If this is the second time you have moved the same date, the email changes. A first slip is a fact. A second slip is a pattern, and pretending otherwise is what turns a project problem into a relationship problem.
Subject: [PROJECT] — Delayed again — [DELIVERABLE] moves to [NEW DATE]
I moved [DELIVERABLE] from [ORIGINAL DATE] to [SECOND DATE] on
[DATE I TOLD YOU]. It is moving again, to [NEW DATE]. That is twice,
and I am not going to present it as a surprise.
What I got wrong the first time: [YOUR ESTIMATE ERROR, PLAINLY].
What is different about this date: [WHY THIS ONE HOLDS — a specific
change, not more confidence].
Confidence in [NEW DATE]: [HIGH / MEDIUM] because [REASON].
What would move it again: [THE REMAINING RISK, NAMED].
OPTIONS
1. [NEW DATE] with full scope as agreed.
2. [EARLIER DATE] with [SPECIFIC THING] cut to phase two.
3. [OTHER OPTION YOU ARE GENUINELY WILLING TO DO].
I would pick [N] because [REASON]. Your call.
NEED FROM YOU: a decision on the above by [DATE].
And the generator. Note how hard it works to keep the model from doing the two things it wants to do here: cushion the opening, and volunteer a recovery date.
Generate a delay notification email to a client.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described.
CRITICAL for this template:
- The new date, the cause and the mitigation must all appear within
the first three lines. Do not open with good news, gratitude,
context, or "I wanted to give you a quick update".
- Do NOT generate, estimate, adjust or round any date. Every date
comes from FACTS verbatim. If NEW DATE is blank, print
"NOT PROVIDED — do not send this until you have a date."
- Do not add a reassurance I did not write. No "we are confident",
no "this will not affect quality", unless it is in FACTS.
- No passive voice in the cause line. Name what happened.
- Do not apologise more than once.
FACTS
Project: [NAME]
Deliverable: [NAME]
Original date: [DATE]
New date: [DATE]
Is this the first slip: [YES / NO — if NO, previous dates: DATES]
Cause, in my words: [ONE SENTENCE]
What I changed so the new date holds: [CONCRETE ACTION]
Unaffected deliverables and their dates: [LIST]
Decision I need from them, if any: [ASK, DATE]
Options I am willing to offer: [LIST, or "none"]
Next update: [DATE]
If the slip is large enough to need a fee or scope conversation, that is a different document and it should not ride along in a status email. The client proposal generator covers the scope-and-price version properly.
Scope changed, or they asked for something new
The status email is where scope creep enters a project, because a request arrives mid-thread and gets a friendly answer. The fix is mechanical: acknowledge, price in time, do not agree in the update.
Subject: [PROJECT] — [STATUS] — week of [DATE] — one scope question
STATUS: [WORD]. [DELIVERABLE] lands [DATE].
NEW REQUEST
You asked for: [THEIR REQUEST, IN THEIR WORDS].
As I understand it, that means: [YOUR RESTATEMENT].
WHAT IT COSTS
Effort: [HOURS OR DAYS].
Effect on [DELIVERABLE]: [MOVES TO DATE / no effect].
Fee: [FIGURE, or "covered by the retainer this month"].
THREE WAYS FORWARD
1. Add it now: [DELIVERABLE] moves to [DATE].
2. Add it to phase two: dates unchanged, separate quote.
3. Swap it for [EXISTING ITEM]: dates and fee unchanged.
I need a pick by [DATE] to keep [DELIVERABLE] on [DATE].
Generate the scope-change section of a client update.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described; never invent a date, an
hour estimate or a fee — those come from FACTS or they print as
NOT PROVIDED.
CRITICAL: do not accept the request on my behalf. Do not write "happy
to", "no problem", "easy enough" or any phrase that reads as
agreement. Present options and a decision date. Restate their request
in one neutral sentence before pricing it.
FACTS
Their request, verbatim: "[QUOTE THEM]"
My restatement: [ONE SENTENCE]
Effort: [HOURS/DAYS]
Effect on current deliverable: [NONE / MOVES TO DATE]
Fee: [FIGURE / covered / NOT PROVIDED]
Options I will offer: [LIST]
Decision needed by: [DATE]
How do you chase a client who is blocking the work?
One specific artefact, one named owner, one date, in the first four lines. Two things go wrong otherwise: the ask gets buried in paragraph four, and it is phrased so gently that nobody registers it as urgent. Both are structural problems, not tone problems.
Subject: [PROJECT] — Blocked — need [ONE THING] by [DATE]
STATUS: Blocked since [DATE]. [DELIVERABLE] is still [DATE] if this
clears by [DATE]. After that it moves.
WHAT I NEED
[ONE THING — be specific. Not "feedback". "Sign-off on the three
headline options in the doc I sent on DATE."]
From: [NAME, ROLE]
By: [DATE]
WHY IT MATTERS
Until it lands I cannot [DOWNSTREAM WORK], which is [N] days of the
remaining schedule.
WHAT I AM DOING MEANWHILE
[PARALLEL WORK, or "Holding — there is nothing else in this phase."]
NEXT UPDATE: [DATE]
If it is the third time you have asked, stop repeating the polite version. Change the register once, and say plainly what happens next.
Subject: [PROJECT] — Blocked — third ask on [ONE THING]
I have asked for [ONE THING] on [DATE], [DATE] and [DATE]. It has not
arrived, so I want to be direct about what happens now.
[DELIVERABLE] moves from [DATE] to approximately [DATE YOU SUPPLY] if
this is not resolved by [DATE].
Three ways to unblock it:
1. [NAME] sends [THING] by [DATE].
2. You delegate the decision to [OTHER NAME] and I work with them.
3. I proceed on [YOUR ASSUMPTION], you accept the rework risk, and
I document that here.
Any of the three works for me. I need one of them by [DATE].
Generate a blocker escalation for a client update.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described; never invent dates.
CRITICAL: the ask must be one specific artefact with a named owner and
a date, in the first four lines. Do not soften it with "whenever you
get a chance", "no rush" or "if possible". Do not write more than one
ask. State the consequence as a fact, not a threat.
FACTS
Blocked since: [DATE]
The one thing I need: [SPECIFIC ARTEFACT]
Owner: [NAME, ROLE]
Asked on: [DATES]
Needed by: [DATE]
What it blocks: [DOWNSTREAM WORK, N DAYS]
Consequence if late: [DELIVERABLE moves to DATE]
Alternatives I will accept: [LIST]
What I am doing meanwhile: [WORK, or "holding"]
When should you warn a client the budget is running out?
At roughly seventy per cent, not at a hundred. At seventy the client has a decision. At a hundred they have a bill.
Subject: [PROJECT] — [STATUS] — [N] of [N] hours used
STATUS: [WORD]. [DELIVERABLE] lands [DATE].
BUDGET
Used: [N] of [N] hours ([N]%) as of [DATE].
Remaining scope needs approximately: [N] hours.
Gap: [N] hours.
WHY THE GAP
[CAUSE — scope added / estimate was light / dependency ate time.
If the estimate was light, say so.]
YOUR OPTIONS
1. Approve [N] more hours at [RATE]. Scope and date unchanged.
2. Cut [SPECIFIC ITEM] to fit the original budget. Date unchanged.
3. Stop at [N] hours and pick the work back up in [PERIOD].
I need a decision by [DATE] to avoid stopping mid-[TASK].
Generate a budget warning inside a weekly client update.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described.
CRITICAL: never calculate, estimate or extrapolate an hour figure, a
percentage, a rate or a total. Every number appears in FACTS verbatim
or prints as NOT PROVIDED. If FACTS is missing the remaining-scope
estimate, do not infer it from the burn rate. Name the cause without
blaming the client unless FACTS says the cause was a client change.
FACTS
Hours used / budget: [N] / [N], as of [DATE]
Remaining scope estimate: [N] hours
Cause of the gap: [ONE SENTENCE]
Rate for additional hours: [FIGURE]
Options I will offer: [LIST]
Decision needed by: [DATE]
How do you tell a client you made a mistake?
Active voice, one apology, and a control that stops the recurrence. The control is the part clients remember, because it is the only part that changes their forecast of working with you.
Subject: [PROJECT] — [WHAT BROKE], and what I have done
[WHAT BROKE] on [DATE]. [WHO OR WHAT IT AFFECTED, PLAINLY —
including "nobody outside the team" if that is true.]
I caused it by [WHAT YOU DID].
What I have already done
[FIX], completed [DATE/TIME].
[VERIFICATION — how you know it is fixed.]
What stops it happening again
[CONTROL — a check, a staging step, a second pair of eyes, a
changed process. Something structural, not "I will be careful".]
What I still need from you
[ASK, or "Nothing."]
I am sorry. Happy to talk it through if useful.
Generate a mistake disclosure to a client.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described; never invent dates.
CRITICAL:
- Active voice in the cause line. "I deployed the wrong branch", not
"an incorrect branch was deployed".
- Apologise exactly once, at the end. Do not open with an apology.
- Do not distribute blame to the client, a vendor or a tool unless
FACTS explicitly assigns it there.
- Do not minimise. Ban "minor", "small", "brief", "slight" and
"just" unless those words are in FACTS.
- The recurrence control must be structural. If FACTS does not
contain one, print: NOT PROVIDED — decide on a control first.
FACTS
What broke: [PLAIN DESCRIPTION]
When: [DATE/TIME]
Who or what was affected: [SCOPE]
My cause, in my words: [ONE SENTENCE]
Fix and when it completed: [ACTION, DATE/TIME]
How I verified it: [CHECK]
Recurrence control: [STRUCTURAL CHANGE]
Ask of the client: [ASK, or "none"]
Handover and wrap-up
The last update is a document, not a farewell. Write it so that someone who has never met you can pick the project up in a year.
Subject: [PROJECT] — Complete — handover
STATUS: Complete as of [DATE].
WHAT YOU HAVE
[DELIVERABLE] — [WHERE IT LIVES, LINK]
[DELIVERABLE] — [WHERE IT LIVES, LINK]
ACCESS AND OWNERSHIP
[ACCOUNT/REPO/DOMAIN] — owner is now [NAME]. Transferred [DATE].
Credentials: [WHERE, e.g. "in the shared vault, item NAME"].
WHAT IS NOT INCLUDED
[THING THEY MIGHT ASSUME IS COVERED AND IS NOT]
[ONGOING COST THEY NOW OWN, and roughly what it is]
KNOWN OPEN ITEMS
[ITEM] — [STATUS AND WHY IT IS OPEN]
IF SOMETHING BREAKS
[WHO TO CONTACT, HOW, AND WHAT RESPONSE THEY CAN EXPECT]
Generate a project handover email.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described; never invent dates, links
or credentials locations.
CRITICAL: include the "not included" and "known open items" sections
even when they are short. If FACTS leaves either blank, print
NOT PROVIDED rather than omitting the heading. Do not add a pitch, a
testimonial request or a referral ask. This is a reference document.
FACTS
Project: [NAME]. Completion date: [DATE]
Deliverables and where they live: [LIST WITH LINKS]
Accounts transferred and to whom: [LIST, DATES]
Credentials location: [WHERE]
Not included: [LIST]
Ongoing costs the client now owns: [LIST]
Known open items: [LIST]
Support arrangement after handover: [TERMS]
How do you restart after going quiet on a client?
Name the gap in sentence one, give the true current state of the work, and offer one specific next step. It is the hardest of these to send and the one people rewrite for an hour, usually because they sit down to draft an explanation instead of a status. Do not explain at length, and do not manufacture a reason.
Subject: [PROJECT] — where things stand
It has been [N] weeks since my last update, and that is on me.
Where the work actually is right now
Done: [ITEMS]
In progress: [ITEMS]
Not started: [ITEMS]
What I am proposing
[ONE CONCRETE NEXT STEP] by [DATE].
A [15/30]-minute call on [TWO OPTIONS] to agree the rest.
If you would rather stop here, say so and I will send a handover of
everything as it stands, with no further charge.
That last paragraph is uncomfortable and it belongs there. It converts a vague, drifting silence into a decision the client can make in one line, which is the only thing that ends the drift. The cold email generator handles the other kind of restarting, where there is no project to report on.
Generate a re-engagement update after a period of silence.
RULES: use only FACTS; print NOT PROVIDED for anything blank; do not
characterise progress I have not described; never invent dates.
CRITICAL:
- Name the gap in the first sentence. Do not bury it.
- Apologise once, briefly, without explanation, unless FACTS gives a
reason I want to share.
- Do not invent a reason for the silence. If FACTS has none, do not
supply one.
- Do not overpromise to compensate. No new deliverables, no
discounts, no accelerated dates that are not in FACTS.
- Include the opt-out line offering a handover.
FACTS
Weeks since last update: [N]
Reason I will share: [ONE LINE, or "none"]
Done / In progress / Not started: [LISTS]
Concrete next step and date: [STEP, DATE]
Call options: [TWO SLOTS]
How do you run this across ten clients without rewriting it?
Split every prompt in two and store the halves separately. The rules, the skeleton and the banned phrases never change. The client name, the project, the dates and the notes change every week and every account. Keeping both in one blob is why people abandon a good prompt after a fortnight: editing becomes find-and-replace, with a real chance of last week's client name surviving into this week's email.
Split them. Save the rules and skeleton once. Keep the per-client facts as named values you fill at send time.
PER-CLIENT BLOCK — save one of these per account
{{client_name}} = [COMPANY]
{{client_reads}} = [ROLE — founder / marketing lead / IT manager]
{{project}} = [PROJECT NAME]
{{delivery_date}} = [CURRENT AGREED DATE]
{{update_day}} = [Friday]
{{tone}} = [plain and short / warmer / more formal]
{{rate}} = [OUT-OF-SCOPE RATE]
{{history}} = [dates already moved, open promises, sore points]
Compress four weekly updates into one monthly summary for [CLIENT].
RULES: use only the four updates below. Add nothing. Any month-level
claim that is not supported by all four prints as NOT PROVIDED.
Do not smooth a bad month into a good one, and do not drop a slipped
date because a later week recovered it — dates that moved stay
visible, with both the original and the current date.
Output:
1. Status now, in one line.
2. Shipped this month: facts only.
3. Dates that moved: original, current, cause.
4. Open asks still outstanding, with how long they have been open.
5. Next month's committed dates — from the updates only, none new.
UPDATES
[PASTE ALL FOUR]
Prompt Architects is built for exactly that split: save the generator as a prompt, keep {{client_name}} and the rest as Global Variables that fill at enhancement time, and put the standing account facts in a Context so you are not re-explaining the project every Friday. The one prompt system, ten clients piece covers the mechanics, and scoping, reporting and client comms covers the wider account-work set. Product managers writing the internal version of this email will want stakeholder updates and release notes instead.
Be clear about which parts of that cost money, because our own pages are not consistent about it. Generating is free: the FAQ page publishes 5 prompt enhancements per day, forever, with no credit card, and that is enough to run every prompt here. Saving them as reusable templates is not free. The comparison table on the pricing page shows Save Prompts, Template Library, Tags & Search, and the Personal Context Library all starting at Pro, with the library capped at 50 prompts on Pro and uncapped on Advanced; checked on the live page on 28 August 2026. That same table renders no Free column at all, so the free plan's storage limits are not published there. Global Variables are documented on the FAQ page but no plan gating for them is published on either page, so check inside the app rather than taking a number from us.
What a client update generator will not fix
Three limits, stated plainly, because a page that only sells the upside is not much use.
It does not know your week. It transcribes and structures what you feed it. Thin notes produce a thin email, and the failure mode is not a gap you can see, it is a smooth paragraph covering one. That is the whole reason for the NOT PROVIDED rule.
It does not send anything, and it does not know your project. Prompt Architects generates and stores the prompt. It is not an email client, it does not schedule a Friday send, and it does not read your task tracker to find out what actually moved. If you want the update assembled from ticket data automatically, that is a job for your project tool's reporting, not for a prompt library, and you should go and use one.
It does not fix a relationship that broke for other reasons. If the client stopped trusting you three months ago, a better-structured Friday email is not the variable. Nobody can tell you from a template whether the honest version of this week's status costs you the account, and I am not going to claim these emails retain clients or get you paid faster, because I have no data that says so.
What they do reliably remove is the hour between "I should update them" and "I updated them", which for most freelancers is the actual reason the difficult update goes out late, thin, or never.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An Account