“We are making progress” is difficult to act on. A useful update lets the client inspect work, make the next decision, and spot a schedule risk while it is still manageable. It can be short; it just needs the same facts every time.
Show evidence of completed work
List the pages, designs, integrations, or content tasks finished since the last update and link to what is reviewable. Distinguish “drafted,” “built on staging,” “client approved,” and “live.” A percentage-complete figure can hide the fact that the remaining work contains the most complex integration. A screenshot can show visual progress but cannot verify a form or mobile behavior; include the appropriate staging link when those are ready to inspect.
If the work is still internal and not ready for client review, say what is being built and what must happen before it is reviewable. The provider should not be expected to publish unfinished work, but the client should know which deliverable is next.
Name every blocker and owner
An update should have a small decision list: what is needed, from whom, by when, and what happens if it is late. “Awaiting content” is vague; “Awaiting approved services copy from the client’s marketing lead by Thursday; service-page review moves until three days after receipt” is actionable. Use dates that the actual team agrees to, not generic turnaround claims.
Separate client dependencies, provider work, and third-party dependencies. An integration awaiting vendor credentials calls for a different response than a design waiting for a client sign-off. If a blocker changes scope or cost, link to the written change request and approval status.
State the next observable milestone
End with the next deliverable, its owner, and the expected review date. A “launch next month” statement is less useful than “staging site with completed service and contact pages ready for client review on the agreed date.” If a prior milestone slips, say what changed and how the downstream plan is affected. Do not quietly replace the old date in a project board; retain the change history.
Agree which channel carries decisions and who may approve them. Slack messages, email threads, and calls can all work, but final scope, price, and launch approvals should be preserved in one reliable project record. If a client is not receiving updates at the agreed cadence, ask for a status meeting and a written recap.
Put the cadence in the project plan
Ask the proposal to specify the update owner, frequency, review channel, decision-maker, and escalation route. The right cadence varies with project size and stage. A short landing page may need fewer formal meetings than a complex migration; every project still needs a way to expose blockers.
ARCHV’s website page describes staged approvals and a written scope. It does not promise a universal weekly update or guaranteed response time; those should be specified for your project. The quote comparison tool can help you flag an undefined communication plan before signing. A public review mentioning vague updates during a changing schedule is one client account, not a measure of how often that issue occurs.