Tell a Customer When Their Request Is Waiting for a Scheduled Review

Describe the status precisely

Use plain language that distinguishes a queue from active work and a completed decision. For example, say the request has been received and is awaiting its scheduled review. If you know the review is planned for a particular meeting or review cycle, you can say that, provided it is accurate. Do not suggest that the review will necessarily happen then if scheduling may change.

Avoid vague phrases such as “being handled” when the customer needs to understand what is happening. Also avoid saying “approved,” “on track,” or “almost done” unless that is genuinely the current status. If you do not know whether the request has been placed on the agenda, say you are checking that detail rather than presenting it as confirmed.

Name the next-action owner

Tell the customer who is expected to act next: a role, team, or named colleague, depending on what you can accurately share. For instance, “Our account review team owns the next step” is clearer than “we will look into it.” If one person is coordinating updates while another group conducts the review, explain that distinction so the customer knows whom to contact.

Do not assign ownership to a person who has not accepted the task or imply that an individual can control a committee or external decision. If responsibility is still being confirmed, say so and make confirming it your own next action. Then tell the customer when you will report back on the owner.

Promise a check-in, not a finish date

A review can take longer than expected, so do not invent a completion date to make the message sound reassuring. Instead, choose a point when you can reliably check the queue and send an update. Tie that point to your real working process—for example, after the next scheduled review session, or by a specific day you can meet. If neither is dependable, commit to a time to confirm the status, not the outcome.

Make the commitment measurable. “I’ll update you by [day and time]” gives the customer a clear expectation. If the review has not happened by then, send the update anyway: explain that it remains pending, say what is known about the next step, and set another realistic check-in. An update can be useful even when there is no decision.

Include only details that help the customer

A concise message usually needs the request being discussed, its current status, the owner of the next action, and the next-update commitment. Add a relevant dependency only when it affects the customer—for example, whether you need a document or clarification before the review can proceed. State exactly what is needed and how to provide it.

Avoid exposing internal debate, speculative reasons for a delay, or details the customer cannot act on. If a meeting date or internal schedule is confidential, describe the expected checkpoint without disclosing it. Be careful with copied recipients: include only people who should receive the request details.

A practical customer update

Adapt this example to the actual request and the commitments your team can keep. Replace every bracketed field before sending, and remove any sentence that is not true. The example promises a status update, not a decision.

Subject: Update on your [request]

Hello [customer name],

We’ve received your request about [brief description]. It is waiting for review; no decision has been made yet. [Review team or named owner] is responsible for the next review step. I’m coordinating the update and will write again by [day and time], even if the review is still pending.

If [specific information] has changed since you submitted the request, please reply with the update. Otherwise, there’s nothing you need to do right now.

Regards,
[Your name]
[Your role or team]

To: [customer]@example.com
From: [your name] <[sender]@example.com>

Check that the expectation was met

Before sending, compare the stated status and owner with what the responsible team has confirmed. Check that the customer’s request is identifiable, the next action has a real owner, and the promised check-in is something you can meet. If you cannot commit to a particular time yet, set a nearer point to confirm the schedule rather than guessing when the review will conclude.

Then make the follow-up visible in your own workflow, using an appropriate reminder or task if available to you. When the promised point arrives, send the update whether the review is complete or not. You can confirm the communication worked by checking that the message was sent to the intended customer and that your follow-up is recorded. Do not treat a sent message as proof that the customer has read or understood it; invite a reply if they need clarification.