Want help applying this guide?Ask the DripTell team
A bicycle reaches a repair shop with an electrical fault, but its removable charger is still at the customer’s home. The technician cannot run the promised test until the customer brings it in. This is a genuine reason to pause the relevant service clock.
Pause a support SLA only when the customer owns one specific next action that is necessary for progress. Do not pause because another team is slow, a supplier has not replied, an approval is pending, or the current owner is away. Those delays still belong to the business.
Pause only for a customer owned next action
An SLA is a service promise, not just a timer in a ticketing tool. A pause removes some elapsed time from that promise, so the evidence must be stronger than a convenient status change.
- 1Name the missing inputAsk for one specific item or decision that is genuinely necessary.
- 2Transfer the next actionTell the customer what they own and what will happen afterward.
- 3Pause the right measureStop only the SLA clock affected by that customer action.
- 4Keep an owner and reviewRetain case ownership and set a date to check the waiting state.
- 5Resume on evidenceRestart immediately when the input arrives and preserve the original age.
Name the missing input in plain language. It could be a photo of the damaged item, confirmation of an address, a choice between two valid remedies, or permission to enter an account. The request must be necessary, proportionate, and possible for the customer to complete. If the team can keep working without it, the case is not truly waiting on the customer.
Microsoft documents configurable SLA pause conditions at the entity, KPI, and SLA item levels, with more specific conditions able to override broader ones. That flexibility is useful, but it also means one generic pending status can affect several clocks in ways an agent may not expect. Define the pause against the exact measure and state you intend to stop.
Separate customer waiting from business waiting
The cleanest test is ownership of the next useful action. If the customer has it, a pause may be fair. If the business or one of its dependencies has it, the clock should normally continue.
Microsoft's SLA timer guidance shows that a case placed on hold moves its SLA KPI instance to paused and retains on-hold timing details, while active and elapsed durations remain separate fields. The point is not to copy a vendor default. It is to decide which promise is being measured before a status changes it.
| Current situation | Owner of the next action | Pause the relevant SLA | What must stay visible |
|---|---|---|---|
| Customer must provide essential evidence | Customer | Yes after a clear request | Missing item, request time, owner, review time |
| Another support team must investigate | Business | No | Current owner, internal assignee, next update |
| A supplier or carrier has not replied | Business | No | External dependency, escalation path, customer promise |
| Customer chose a future date for work | Shared agreement | Only for the agreed measure | Appointment, timezone, restart trigger |
| Team sent a vague request for more details | Unclear | No | Exact question and why it is necessary |
This distinction protects both sides. The agent is not penalized for time the customer genuinely controls, and the business cannot improve its reports by hiding its own queue or dependency delays.
Record the pause as an auditable event
A valid pause needs more than a status. Store the precise input requested, the customer-facing message, who owns the case while it waits, when the pause began, when the team will review it, and the event that will resume work. Keep the original arrival time as well as paused duration. Otherwise the case can return to the queue looking new.
The message to the customer should say what is needed and what happens next. For example, the bicycle shop can ask for the charger, explain that diagnosis cannot continue without it, and say the case will resume when the charger arrives. Avoid open requests such as “send more information.” They make it difficult to tell whether the customer has actually completed the action.
Use a short review date even when there is no fixed deadline. A waiting case still needs an owner. That person may send one proportionate reminder, offer another way to provide the input, or decide that the request was unnecessary. A pause must never become an invisible shelf for uncomfortable work.
Resume without losing the original age
Resume the SLA as soon as the required evidence arrives through any connected channel. A customer may answer the email request in WhatsApp or call with the information. Matching the event to the same customer and case matters more than receiving it in the original window.
Preserve the time before the pause, the paused interval, and the time after resumption. Do not reset the case to zero. The customer’s total elapsed wait should remain available even if the contracted or internal SLA excludes part of it. This is consistent with measuring every customer wait in a fair next reply view rather than allowing a status to erase history.
When the customer never replies, use the transparent inactivity rule from your case closure policy. Close only when the customer was told about the window and the business owes no unfinished action. Silence is not proof that the problem disappeared.
Measure waiting without hiding it
Report active work, customer waiting, and business dependency time separately. Review the median and slow tail for each state, the number of pauses without a specific request, cases that resumed without an owner, and cases closed directly from a paused state. Sample the underlying conversations because a clean status history can still hide a poor request.
In DripTell, a support workflow can keep the next action visible, while the shared inbox preserves the owner and conversation history. Workflow automation can respond to a customer event, but the pause policy still needs a human owner and tested conditions. Limit who may change those rules with appropriate security controls.
The rule is simple enough to remember. Pause only when the customer has the necessary next move. Keep the business clock honest everywhere else.
Frequently Asked Questions
When should a support SLA pause?
Pause only when the customer has been asked for a specific, necessary input or decision and progress genuinely cannot continue without it. Record the request, owner, start time, review time, and resume event.
Should an SLA pause while waiting for another team?
Normally no. An internal team, supplier, carrier, or approval process remains part of the business delivery chain. Keep the clock running and make the dependency and customer update owner visible.
What should happen when the customer replies?
Resume the relevant clock immediately, return the case to an accountable owner, and preserve its original age plus the paused duration. Match replies from other connected channels to the same case where identity is reliable.
Can automation pause an SLA?
Automation can pause when it sees a precise verified condition, but it should not infer customer ownership from a vague pending label. Test missing data, cross-channel replies, duplicate events, timeouts, and manual recovery before relying on the rule.
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