Practical guide

Write status updates that answer the client’s next question

Last materially reviewed 2026-09-19

Quick answerA useful update says what happened, what happens next and whether the client needs to act.
What to know

Lead with the deliverable

Clients usually care about their output, not the internal mechanics of your board. Begin with the named request and its current state. “Your campaign banner is awaiting approval of V3” is clearer than “Task moved to review.” ManyRequests sends several types of notification, but the existence of an email does not guarantee that the recipient understands the next action. Use the request record as the durable context for the update.

What to know

Use a three-part message

Our simple structure is outcome, next step and dependency. An example reads: “The first deck layout is ready. Please review the linked V2 by the agreed review time. We need one consolidated response before preparing the final export.” Adapt dates and promises to the actual agreement. Do not invent a delivery date merely to make the message sound confident. A truthful unknown with a named next check is more useful than false certainty.

What to know

Avoid noisy reassurance

Repeated “working on it” messages add little if no state has changed. Explain a meaningful event, a newly identified blocker or a decision that affects the client. Keep sensitive internal discussion separate from client-facing notes. If an automatic notification already communicates the event accurately, a second manual message may be unnecessary. The aim is useful visibility, not maximizing the number of emails or making a slow process appear busy.

What to know

Keep recovery understandable

When something goes wrong, refer to the original request and describe what is known. Distinguish a missing notification from missing work before asking the customer to submit again. If the outcome is uncertain, say what you will check and avoid promising that a duplicate action is harmless. Good status communication reduces the effort required from the client while preserving the evidence your team needs to resolve the issue responsibly.

Continue when useful

Next: Missing notification or missing work? Check before repeating an action

An absent email is not proof that a request, comment or invoice was never created.

Open Missing notification or missing work? Check before repeating an action →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. ManyRequests notification email types — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
  2. ManyRequests managing requests and exporting data — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19