Want help applying this guide?Ask the DripTell team
A customer was told on Monday that the team was investigating a missing refund. By Thursday, the case still showed “open,” but nobody had explained what had changed, who was waiting for whom, or when the customer would hear again. The team had an internal status. The customer had silence.
When an issue is still unresolved, send a short update that states the customer impact, the confirmed current state, the next action, its owner, and the time of the next update. Do not invent a cause or promise a resolution date you cannot control. A useful update reduces uncertainty even when it cannot yet remove the problem.
A status change is not a customer update
Internal ticket states help a team organize work, but they do not necessarily tell the customer anything. Microsoft's current case-status documentation shows that an active case can be in progress, on hold, waiting for details, or under research.
“Pending,” “escalated,” or “with engineering” may be precise inside the company and meaningless outside it. Translate the state into the customer's situation. Say what is affected, what has been confirmed, and whether the customer needs to act.
The support operating model should define both the internal state and the public explanation. Otherwise each agent has to improvise under pressure.
Say what is true now
Start with the latest confirmed fact, not a vague apology. “The refund has not reached your card” is clearer than “Your case is progressing.” If the cause is unknown, say that the team is still checking it. A careful unknown is more trustworthy than a confident guess that later changes.
- 1State the impactName what the unresolved issue prevents or changes for the customer.
- 2Confirm the current stateSeparate verified facts from causes or dates that remain unknown.
- 3Name the ownerIdentify the team or role accountable for the next step and communication.
- 4State the next actionExplain the concrete check, request, or decision that happens next.
- 5Set the next updatePromise a specific communication time even if the issue may remain open.
Separate facts from actions. The fact may be that the payment processor has not confirmed the reversal. The action may be that the billing owner has sent a trace request. Keep both in the shared inbox with the original conversation so a later agent does not rewrite the story from memory.
Say whether the customer must act. Use a direct line such as “You do not need to send anything else today.” Never ask for information already present in the thread.
Give the next action an owner
“We are working on it” hides responsibility. Name the team or role taking the next action, even if you do not name an individual. Then state the action in plain language. “Our billing team is checking whether the reversal left our account” is better than “This has been escalated.”
Ownership should also be visible internally. The customer record needs one current owner, one next action, and one due time. A transfer is not complete merely because the destination queue received the case. Someone must accept the work and preserve promises already made.
| Current situation | What the customer should hear | Promise to avoid | Internal owner |
|---|---|---|---|
| Waiting for the customer | The exact missing fact and why it is needed | A resolution before the reply arrives | Current support owner |
| Waiting for another team | What that team is checking and when you will follow up | That the other team will finish by an unconfirmed date | Coordinating owner |
| Waiting for an outside party | Which dependency is open and what remains available | A supplier deadline you do not control | Case owner |
| Cause still unknown | Confirmed impact and the next diagnostic step | A speculative explanation | Investigation owner |
Promise the next update instead of the outcome
The safest time commitment is often the next communication, not the final fix. Say, “I will update you by 3 pm tomorrow, even if the investigation is still open.” That gives the customer a reliable checkpoint without pretending the outcome is known.
Choose the checkpoint from the customer's consequence. A blocked payment may need an update within hours; a cosmetic defect may justify longer. Microsoft's case follow-up documentation describes periodic emails based on case status and configured response intervals. Those are useful triggers, but the promised cadence must fit the customer's impact.
If the promised time arrives with no new answer, send the update anyway. “There is no final decision yet” is still useful when it is followed by the latest action and a new checkpoint. Missing the update creates a second failure that the original dependency does not excuse.
Match the message to the wait
Different waits need different wording. When the team needs information from the customer, ask one clear question and explain why it matters. When an internal specialist owns the next step, keep the original support owner responsible for communication. When an outside party is involved, name the dependency without shifting blame.
For a high-impact delay, offer a safe workaround if one exists and state its limits. Do not present a risky manual process as harmless. If no workaround exists, say so plainly.
The automation builder can schedule reminders and route overdue actions, but it should not generate certainty. An automation may notice that an update is due. The accountable owner must confirm the facts before the message goes out.
Check whether updates reduce uncertainty
Do not judge the update only by whether it was sent. Review whether the customer asked “any news?” again before the promised checkpoint, whether the owner missed the checkpoint, whether the customer repeated information, and whether a later agent contradicted an earlier message.
Sample difficult cases, not only clean ones. Look at long waits, transfers, outside dependencies, and messages sent with no new resolution. In the WhatsApp channel, keep the same standards as email or web chat. Shorter messages still need a true state, owner, next action, and next update.
A good customer support status update does not make an unresolved issue look solved. It makes the remaining uncertainty visible and owned. If your team cannot reconstruct those five elements from the conversation history, test one real delayed case in a DripTell working session before automating the cadence.
Frequently Asked Questions
What should a customer support status update include
Include the customer impact, the latest confirmed state, the next action, who owns it, whether the customer must do anything, and when the next update will arrive.
Should you give an estimated resolution time
Only when the estimate is supported by the team or dependency that controls the work. Otherwise promise a specific next update time and explain what will happen before then.
What if nothing has changed by the promised update
Send the update on time. Say that the issue remains open, name the most recent action, explain any confirmed dependency, and set the next checkpoint. Silence is not a neutral option.
Can customer updates be automated
Automate reminders, routing, and approved messages for stable events. Require a responsible person to verify facts when the cause, impact, workaround, or completion time is uncertain.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy