When a customer’s requested outcome depends on another company, team, or decision-maker, a vague “we’re working on it” can sound like a promise you cannot keep. The more useful response names the dependency, explains what your team has already done, and draws a clear line around what remains outside your control. Then give the customer a reliable update condition: what event will prompt you to write again, even if the final answer has not arrived. This keeps the conversation honest and gives both sides a practical next step without guessing at a deadline.
The useful bits
- Name the specific outside party or process and what you are waiting for.
- Separate your team’s actions from decisions or timing you do not control.
- Set an update trigger you can meet, not a completion date you cannot guarantee.
Describe the dependency, not just the delay
Tell the customer what must happen before their requested outcome is possible. Be as specific as you can without speculating: for example, “We need the payment processor to confirm whether the transaction was accepted,” rather than “This is taking longer than expected.” If appropriate, identify the outside party by name. If naming it would expose confidential information or confuse the customer, describe its role instead.
Explain why that step matters to the request. A customer may hear “we’re waiting on a partner” as a handoff or an excuse unless you connect it to the result they asked for. Keep the explanation short and avoid implying that the external party has agreed to a particular outcome or timeframe.
Draw the boundary around your control
Separate actions your team can take from decisions another party must make. You might control whether you submit a complete request, provide relevant records, check for a response, and explain the next available options. You may not control the other party’s review, its decision, or when it replies.
State both sides plainly. Avoid wording such as “we’ll get this resolved” when resolution depends on someone else. A more accurate statement is, “We’ve sent the requested information and can follow up with the processor; it makes the decision on whether the transaction can be reversed.” This communicates ownership of your part without taking credit for a result you cannot deliver.
Offer a next step the customer can understand
Give the customer a short account of what has happened and what happens next. If you still need information from them, ask for the specific item and explain how it relates to the request. If you do not need anything else, say so. Do not make the customer repeat details already available to your team unless there is a clear reason.
Where possible, explain what you will do while the dependency is pending. For instance, you can say that your team will check for a response and contact the customer when there is a material update. Do not suggest that you can speed up another party’s process unless you know that is within your authority.
Use an event as the update condition
When you cannot responsibly estimate completion, avoid inventing a date. Instead, identify the condition that will prompt your next message: receiving a decision, learning that the request needs more information, or reaching a point when you can verify the status again. An update condition is not a promise that the external party will respond by then; it is a commitment about what your team will do when the stated event occurs.
Make the condition concrete enough to follow through on. “We’ll update you when we hear back” may be appropriate if you will monitor the request, but it can leave the customer wondering whether anyone is checking. You can clarify the process without promising a particular reply time: “We’ll check the request again at our next review and contact you if its status changes.” Use that wording only if your team can actually perform that check.
Example: a decision belongs to a payment processor
Suppose a customer asks your team to reverse a charge, but the processor must decide whether the transaction qualifies. Your team has submitted the details, but has not received a decision. A useful reply names the dependency, distinguishes the roles, and sets an update condition without guessing when the decision will arrive.
Subject: Update on [transaction reference] Hello [customer name], We’ve sent [the information submitted] to [payment processor name] for review. The processor must decide whether this transaction can be reversed; our team cannot make that decision on its behalf. We can check the request and let you know when the processor responds or if it asks for more information. We don’t have a confirmed decision date, so I don’t want to give you an estimate that may not hold. You don’t need to send anything else unless we contact you with a specific request. Regards, [agent name]
Check that the message sets a real expectation
Before sending, confirm that the named dependency is accurate, your own actions are described in the past tense only if they are complete, and the customer knows whether they need to do anything. Check that the update condition is something your team can honor. If the external party has not given a deadline, do not turn an internal hope into a customer-facing commitment.
The response has worked as a communication step when the customer can tell who owns the decision, what your team is doing, and what event will bring the next update. Record the agreed follow-up condition in the appropriate case notes or handoff so another team member can continue consistently. If the dependency changes, correct the expectation promptly rather than repeating an outdated assurance.
- Can the customer identify the outside decision-maker or process?
- Have you separated your team’s actions from what it cannot decide or schedule?
- Is the next update tied to a realistic event, with no unsupported completion date?
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