When a customer’s request depends on something that is not ready, a vague update such as “we’re waiting on a few things” leaves them guessing. They need to know exactly what is outstanding, who is responsible for checking it, and whether any part of their request can move forward meanwhile. A clear message does not hide the delay or promise a resolution date you cannot control. It gives the customer enough detail to understand the pause and a simple way to know when they will hear from you again.
The useful bits
- Name the missing item or decision in terms the customer can understand.
- Identify who will check it and when you will provide the next update.
- Separate work that is paused from useful work that can continue.
Describe the dependency, not just the delay
State what the request is waiting for and why that item matters. Use a concrete noun: an approval, a file, access to an account, or confirmation of a setting. If the dependency is an internal review, explain what the reviewer needs to decide without exposing irrelevant internal detail.
Avoid shorthand such as “blocked,” “pending,” or “with the team” on its own. Those words describe your workflow, not the customer's situation. Translate them into the practical effect: “We can’t schedule the change until we receive your approval of the revised date.”
Be precise about uncertainty. If you do not yet know whether a document is sufficient, say that it needs review rather than implying it has been accepted. Do not suggest that the customer caused the delay unless that is both clear and necessary.
Make responsibility visible
Say who is taking the next action. That may be the customer, your team, or another named party. If the customer needs to provide something, describe what counts as complete and where to send it. If your team is checking, name the team or role in plain language and say what it is checking.
One person should own the next update even when several people are involved in the work. The owner does not need to control the dependency; they are responsible for checking its status and keeping the customer informed. Avoid making the customer chase an unnamed group.
If the next check has no firm completion date, give an update point you can keep, such as when you will contact them again. Make clear that this is a check-in, not a promise that the dependency will be resolved by then.
Separate the paused work from the possible work
Explain what cannot proceed until the dependency is resolved, then say whether anything useful can continue. For example, you may be able to prepare a draft while waiting for approval, but not publish it. If no meaningful work can continue, say so directly rather than implying progress that is not happening.
Be careful not to describe preparatory work as completion. A draft, review, or provisional plan may help reduce later delay, but it does not remove the dependency. Tell the customer whether that work could need to change once the missing information arrives.
This distinction helps the customer decide whether to send the requested item, revise priorities, or wait. It also prevents different expectations about what “in progress” means.
Give a clear next step and a realistic update point
Ask for one specific action at a time where possible. Include the detail that will help the customer respond correctly, such as which version needs approval or what information is missing. Do not ask them to resend material you already have unless you explain why it is needed again.
If another party must act, say when you will check with them or when you will update the customer. Choose a point you can control. If circumstances change before then, send an update rather than letting the earlier message stand as though the situation were unchanged.
Avoid promising that the request will be finished by a date that depends on an unconfirmed approval or response. If the customer asks for a completion estimate, identify the dependency and explain what information is still needed to make a more useful estimate.
A message that puts the pieces together
Use this example as a structure, not a script. Replace each bracketed field with verified details, and remove any sentence that does not apply. The responsibility and update point should match what you can actually do.
Subject: Update on [request] Hi [customer name], We’re waiting for [specific approval or item] before we can [paused action]. This is needed because [brief plain-language reason]. [Person or team] is responsible for checking [dependency]. While that is pending, we can [specific work that can continue]; we can’t [specific work that must wait]. The preparatory work may need to change if [relevant condition]. I’ll check the status and update you by [date or agreed check-in point], even if there is no change. If you can provide [customer action], please send it to [contact or agreed channel]. Best, [Your name]
Confirm that the handoff is understood
After sending the update, check that the request is recorded with the dependency, its owner, and the next check-in point. If your team uses a task or case record, make the status specific enough that a colleague can tell what is waiting without interpreting “pending” on their own.
When the customer responds, confirm whether the required item arrived and whether it answers the stated need. Receipt is not the same as approval: if someone still needs to review it, tell the customer that review remains outstanding and give the next update point.
You can confirm the communication worked by checking whether the customer knows what to provide, who is checking the dependency, what can proceed, and when they will hear from you. If any answer is unclear, clarify it directly rather than assuming silence means agreement.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction