Say you're a freelance QA tester on a three-month contract with a small agency. Every Friday you owe the client a short status email: what you found, what got fixed, what's still open. The first one goes fine. By week four, the email is technically accurate and still annoys the client, because it ignores things they told you in week one.
I build Maildoer, an email assistant, and near the end I'll show how it handles that week-four problem. Most of this post is the structure and checks I'd use no matter who writes the email.
Why bug-status emails go wrong
A tracker export answers "what's in the system?". The client reading your email on a phone wants to know:
- Is anything blocking launch?
- What changed since last Friday?
- Do they need to decide anything?
The raw export can't answer number 2, and it has no idea what the client already asked for. Typical week-one requests look like this:
- "Group issues by page, not by severity. Our designers think in pages."
- "Don't paste staging links. This email gets forwarded to people who shouldn't have them."
- "Call it 'won't fix this release', never 'rejected'. The dev team is touchy."
None of these live in the tracker. They live in an email thread from three weeks ago.
A template that survives forwarding
Subject: QA status, week N: [X blockers / no blockers]
1. Launch blockers (or "None this week")
- Page > issue, one line each, current owner
2. Changed since last Friday
- Fixed and verified: count + the ones they'll notice
- New: one line each, grouped by page
- Re-opened: why, in one sentence
3. Decisions needed from you
- The question, the options, the default if we hear nothing by [day]
4. Still open, not blocking
- Count per page; full list attached
Standing rules for this client:
- grouped by page / no staging URLs / "won't fix this release"
The last block is the important one. Keep it at the bottom of your own draft (delete it before sending if you like). It's a checklist you re-read every Friday.
Four checks before you hit send
- Diff, don't dump. If "changed since last Friday" is longer than the full list was last week, you're re-reporting old issues.
-
Search for forbidden strings. Find
staging.and any internal ticket prefix before sending. One forwarded link is enough to lose trust. - One decision per bullet. "Should we A or B, default A on Wednesday" gets answered. A paragraph doesn't.
- Read the subject line alone. It's often all the client's boss sees.
Week four is the real test
The hard part isn't writing a good first status email. It's the fourth one, when you're tired, the export has changed shape, and the client's week-one rules are buried. If you hand this job to someone else, a contractor or a tool, the same thing applies: give them the earlier thread too, not just this week's CSV.
That's the part I cared about most when building Maildoer. It doesn't read a new email from someone as if it were the first one. When it works on your week-four request, it connects it to your earlier emails, so "same format as last Friday, here's the new export" keeps the page grouping and the no-staging-links rule you set in week one. If something's off in the result, you reply to that result and say what to change. You don't start over.
Here's the brief I'd send in week one:
Attached: tracker export (CSV). Draft my weekly QA status email to the client using this structure: blockers, changed since last week, decisions needed, still open. Group by page, not severity. Never include staging URLs. Say "won't fix this release" instead of "rejected". Keep it short enough to read on a phone.
And in week four, just:
Same as last Friday. New export attached. One extra thing: the checkout page is a blocker now.
Whatever you use, write down the client's standing rules once and carry them forward every week. That habit does most of the work.
If you want to test the week-four brief on your own export, email the file and your ask to do@maildoer.com. Your first email gets 100 credits to try it. https://maildoer.com
Top comments (0)