BlogServices
Service response times: when the clock runs or waits
A receipt and a resolution measure different things. Define working calendars and permitted pauses before trusting the service timer.
Check ten service-clock rules
Includes Friday-to-Monday hours, pauses, valid response and reopening. Record observed results after testing.
Define what counts as a response and which clock you measure
A service target is useful when everyone understands its start event, working schedule, pause conditions and finishing evidence. First response and resolution are different commitments. An automatic receipt can inform the customer without showing that a person understood the case or that the problem was resolved.
Microsoft documents service targets with applicability, success and pause conditions, calculated using configured working hours and closures. In Dynamics 365 Customer Service, no assigned schedule means all day, every day. These are that product's rules; explicitly verify the calendar and conditions of the system you evaluate.
| Rule | Business decision | Evidence |
|---|---|---|
| Start | Receipt, classification or another agreed event | Time and original request |
| Schedule | Days, hours, holidays and time zone | Current calendar |
| First response | Which intervention counts as attention | Message or action and owner |
| Pause | Allowed reasons and approval authority | Start, reason and missing requirement |
| Resolution | Which outcome needs acceptance | Result and closure condition |
| Reopening | Continue, restart or require review | Rule and link to previous case |
Example: a Friday request waiting for customer information
First response is due Monday 12 at 10:30: Friday contributes thirty minutes until 17:00, leaving ninety from Monday 09:00. An automatic 16:31 message does not satisfy this test rule. The owner responds at 16:45 with context, required information and next action. First response is fifteen working minutes.
At 16:50 an authorized wait is recorded because essential information is missing. Resolution has consumed twenty minutes from 16:30. The customer provides the information Monday 09:30 and the clock resumes. Three hours and forty minutes remain: Monday 13:10 is the deadline. Preserve original times and the excluded interval on screen.
If the accepted outcome arrives at 13:00, resolution used twenty Friday minutes plus three hours and thirty on Monday: three hours and fifty. If it arrives at 13:15, the total is four hours and five, five minutes beyond the target. These are independent example variants, neither actual service results nor a contractual guarantee.
A pause needs a verifiable reason and next action
Do not stop the clock merely because the queue is full or someone forgot the case. Under this policy, an internal spare-part wait does not pause resolution. The record identifies the missing requirement, requester, wait start and person checking whether it arrived. Renaming a state pending should not itself determine excluded time.
| Situation | Expected outcome | Check |
|---|---|---|
| Same customer uses another channel | Link to the same case and preserve original start | Do not refresh the deadline with another ticket |
| Same pause recorded again | One interval, not deducted twice | Reference, start and finish |
| Reopened because outcome was not accepted | Apply reopening rule and keep history | Do not conceal lateness with a new date |
| Priority changes during the case | Visible decision and agreed calculation rule | Previous and new target |
| Different hours or holiday | Use the approved calendar | Version and time zone |
If information arrives outside working hours, preserve its receipt time and calculate resumption under your rule. Also define what happens if it never arrives: permitted reminder, escalation or closure with reason. Closing for no response does not equal technical resolution. This guide determines neither penalties nor legal service-agreement interpretation.
Evaluate the counter using known times
- Create a case near Friday closing and calculate its deadline manually. Check first response and resolution separately.
- Add an allowed wait and an unapproved internal wait. Exclude only the interval authorized by the rule.
- Receive the requested information and verify resumption. Repeating the event must preserve one interval without another deduction.
- Link messages about the same problem from two channels. The owner must see the original start and commitment.
- Test rejected closure, reopening and priority changes. Preserve reasons and show any outstanding review.
Before selecting software, gather working hours, holidays, time zones, priority types and three cases with verifiable times. Define examples of valid response, acceptable resolution and allowed pause. If staff cannot explain these rules, an attractive counter provides only apparent precision.
To turn rules into shared work, review documenting processes; for cases requiring visits, crew scheduling. A service business software consultation can examine the clock and evidence each commitment needs.
Frequently asked questions
Only if the agreed rule defines it that way. This guide's test requires a person to provide context and next action; a receipt notice does not meet that criterion.
No. Define allowed reasons, approval and the target paused. An internal wait may keep consuming time even if the request appears pending.
Use an explicit calendar with working hours and time zone. Test known dates; record who authorizes calendar changes and their impact on open cases.
That is a business or applicable agreement decision. Define the rule, preserve the link and previous times, and avoid restarting to hide a missed target.
Sources
- Configure service-level agreementsMicrosoft Learn
Last updated: