Weekly status is a decision tool—not a timesheet diary
Clients skip weekly status not only because they are busy, but because it does not scan: long done-lists, no decision asks, risks buried at the end, dead links or VPN-only demos. An agency weekly should answer in three minutes: is the project healthy, what changed, what do you need from the client, what is blocking. At KSX Studio, status is part of communication cadence across discover→design→build→launch, with preview links and checkbox decisions. On TOSPUR-class platforms or brand redesigns, transparent status reduces “feels stuck” trust drain. Below: a copyable structure and anti-patterns.
Subject line: project, period, health light
Subject: `[Project] Weekly 2026-07-14–07-20 · Green/Amber/Red`. Define lights up front: green = on plan; amber = risk with mitigation; red = milestone slips unless a decision lands now. Ban “mostly fine.” Separate decision owners from FYI watchers; if two+ owners, name this week’s primary. Reply in one thread so search works—do not invent a new subject every week.
Bottom line up front: five-sentence summary
Open with five sentences: (1) did this week’s goal complete; (2) impact on milestone dates; (3) the single biggest risk; (4) what the client must finish this week; (5) next week’s one-glance goal. A busy CEO or marketing lead may only read these—if they fail, the rest is noise. Do not summarize as “we worked hard.” Use outcome language: staging green, copy pending, API still 500.
Evidence: preview, screenshots, metrics—not hours
Attach a clickable preview deploy, 30–60s clips of critical pages, defect trend or performance samples. Timesheets are for finance, not business decision-makers. If auth is required, create a read-only account that week and document it. Annotate screenshots with “please approve” hotspots. For cross-border China teams, access paths matter: a link the client cannot open is not evidence. Treat preview-link reliability as part of delivery quality.
Decision request table: the only thing allowed to slip dates
Table: decision | options | recommendation | due | consequence if late. Examples: hero A/B, whether third-party pay is in scope, who owns final copy. A decision without a due date is not a request. When the client is late, turn the light amber/red and replan in the open—do not silently overtime to hide it. That protects scope and the relationship, and trains both sides to treat decisions as critical path.
Risks and dependencies: early, mitigable
Each risk: description, likelihood/impact (brief), mitigation, owner (us/client/third party). Dependencies include brand assets, legal review, API integration, domain/certs, store accounts. Avoid scare lines (“we might be late”) with no plan. Red risks belong in the summary—not an attachment. The same risk two weeks with no movement becomes a short escalation meeting, not a pasted paragraph.
Done and next: map to milestones
Phrase done as user/business-visible change: nav IA frozen, form anti-spam on staging, zh/en hreflang wired. Avoid “continued homepage development.” Next week: max five items, each checkable in the following status. In launch week, switch to launch-checklist progress (DNS, monitoring, rollback, content freeze). When phases change, state “from this week, communication focus shifts to…”
Changes and scope: make quiet cost visible
List new/confirmed change tickets, effort impact, milestone movement. Accumulated micro-copy tweaks must surface—or the light stays green while the team burns. Keep an open-change count. On retainers, separate in-plan optimization from out-of-plan projects so status does not become an unbounded wish list.
Cadence, tools, and pause rules
Send on a fixed weekday and timezone; declare holiday pauses or biweekly merges early. Tools may be email + shared doc + PM link, but the summary must stand alone without five logins. Emergencies do not wait for Friday: sync red lights same day. In kickoff, demo a blank weekly template so clients learn the fields. Good status shortens the weekly meeting to open decisions—not re-reading the done list.
Checklist
- 1Subject includes period and green/amber/red with agreed definitions
- 2Five-sentence summary includes milestone impact and client todos
- 3Preview or recording opens on the client side with account notes
- 4Decision table includes due dates and late consequences
- 5Open-change count and risk owners updated
Key takeaways
- Clients read decisions and risks—not your task-tracker export
- Status without evidence links forces clients to trust vibes
- Late decisions must change the light and the plan—hiding them burns trust
FAQ
- What if the client only wants WeChat voice updates?
- Voice can supplement, but the five-sentence summary and decision table still go in writing for boss-forwarding and audit. Agree a five-minute voice walkthrough of the written status—not voice as the only record.
- How long should weekly status be?
- Summary fits one screen; 400–800 Chinese characters-equivalent or modest English is usually enough. Attach detailed bug lists. More than two pages without a decision table means structure failed, not “not enough info.”
- How do we merge design, eng, and SEO workstreams?
- One status, three short subsections, light = worst of the three. Cross-dependencies go in the risk table. Do not send three emails for the client to assemble. One editor owns the weekly; others contribute bullets.