Free mini-course · 45 minutes · No account needed
Route customer requests and manage a queue without premature closure
Separate routing from urgency, plan a fixed work window and reconcile action evidence before closing requests. Produce a checked customer-service handoff.
For a customer-service coordinator using a small intake queue. All rules are fictional; no customer accounts or personal information are needed.
What you will make
A triage portfolio with route and information holds, a bounded work-window plan and closure/follow-up lists tied to evidence.
- Assign an owner and identify missing information without confusing either with urgency.
- Choose a queue under an explicit priority and time-capacity policy.
- Distinguish an action submitted from a verified and communicated resolution.
The exercise contract
All records, policies and outcomes in this course are fictional. The supplied contract determines the expected answers.
- Use the supplied fictional routing and queue rules only; they are not a universal service policy. No legal, medical or safety emergency handling is modeled.
- Unit 1 routes by topic: billing→billing, technical→technical, delivery→delivery. A missing order reference holds the request for information. service_stopped=yes marks urgency independently.
- Unit 2 sorts priority ascending, then created time ascending, then ticket ID alphabetically. Use a 40-minute window, take whole tasks in that order and stop when the next task cannot fit. Do not skip or partly complete a task.
- Unit 3 closes a request only when its action is confirmed and the customer has been informed. Keep pending confirmation, missing notification and missing owner/date as separate follow-ups.
Name the owner without losing an information hold.
1. Separate route, urgency and missing information
A useful intake record answers several questions: what is being requested, who owns it, what information is missing and how urgent it is. Treat these as separate fields. A technical topic does not automatically mean urgent, and an urgent request can still lack information needed for action.
Apply the routing table consistently. Billing, technical and delivery requests go to their matching teams only when the required order reference is present. An absent reference becomes a needs-information item with a follow-up owner, not a guessed order number or a completed case.
Urgency is a separate yes/no flag in this fixture. Count a service-stopped request as urgent even if another field needs clarification. This prevents an administrative hold from concealing the need for prompt attention. The exercise does not define a response-time commitment or emergency protocol.
A handoff should show ready work and information holds together. Record the reason for the hold and the next question to ask. Avoid putting unrelated tickets into a single miscellaneous category, because the next person then has to repeat the triage before doing useful work.
Try it yourself
Use the supplied intake rules. The ready-to-route count includes requests with an order reference, regardless of urgency.
Anonymous request intake
| ticket id | topic | order reference | service stopped |
|---|---|---|---|
| T1 | billing | O11 | no |
| T2 | technical | O12 | yes |
| T3 | billing | no | |
| T4 | delivery | O14 | no |
| T5 | technical | O15 | yes |
Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.
Read this exercise’s solution
Technical: T2/T5. Billing: T1. Delivery: T4. T3 needs its order reference. T2/T5 are urgent. Four ready records plus one information hold reconcile to five.
Apply the idea
How would you preserve urgency if the missing-reference record also reported service stopped?
Apply the stated order and whole-task capacity rule.
2. Plan a queue within a fixed work window
A queue needs a tie-breaker, not just a priority label. This fixture sorts lower priority numbers first, then earlier creation time, then alphabetical ID. Use all three rules so another coordinator obtains the same first and second ticket. The sequence is a supplied exercise policy, not a measure of customer value.
Capacity is time in this unit. Begin with 40 minutes and subtract the full task estimate before taking the next one. The policy allows neither partial work nor skipping ahead to a shorter task when the next cannot fit. A different team could choose another policy, but changing it silently would invalidate this comparison.
Keep selected, remaining and unused capacity explicit. A task outside today’s window is still open work; it is not rejected or resolved. Your handoff should identify the next queued ticket so the next coordinator can continue without sorting the list again.
Estimated effort is not a promised response deadline. The fixture does not model interruptions, arrival of new work or uncertainty. If any of those change, version the plan and rerun the ordering rather than claiming that a tidy 40-minute calculation proves service performance.
Try it yourself
Plan the 40-minute window from this new ready queue. Enter ID sets for selected and remaining work, and choose the next queued task.
Ready work estimates
| ticket id | priority | created time | minutes |
|---|---|---|---|
| A | 1 | 09:20 | 20 |
| B | 2 | 09:00 | 10 |
| C | 1 | 09:10 | 15 |
| D | 1 | 09:10 | 25 |
| E | 2 | 08:50 | 5 |
Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.
Read this exercise’s solution
Queue C,D,A,E,B. Select C/D for 40 minutes, leaving 0. A/E/B remain open and A is next. The plan is conditional on the supplied estimates and no interruptions.
Apply the idea
If D’s estimate rises to 30 minutes before work starts, what does the no-skip policy require after selecting C?
Retain pending actions and customer notifications as visible work.
3. Close only when the required evidence exists
An action request and its successful completion are different states. Submitting a refund is not the same as confirmation that it was processed. A delivery date can be confirmed while the customer still has not been told. Keep these distinctions visible rather than treating any action note as resolution.
The fictional closure rule requires both confirmation and customer notification. Check those fields for each record. When confirmation is pending, retain an investigation follow-up; when confirmation is complete but notification is missing, assign the communication step. Neither situation qualifies for closure under the supplied policy.
A promised callback without an owner or date is also unresolved. Giving it a new priority label does not create ownership. Request the missing commitment from the responsible team and preserve the open item until the record contains a usable next action.
Reconcile the end-of-window states as carefully as the initial queue. One case closed, one confirmation pending, one notification needed and one missing owner/date account for all four records below. This prevents an activity count from being presented as a resolution count.
Try it yourself
Classify each record under the closure rule. unknown owner/date means that a usable follow-up commitment still needs to be obtained.
End-of-window evidence
| ticket id | action | confirmation | customer informed | followup owner date |
|---|---|---|---|---|
| S1 | refund submitted | pending | no | billing tomorrow |
| S2 | delivery date confirmed | yes | no | delivery today |
| S3 | technical fix confirmed | yes | yes | complete |
| S4 | callback promised | pending | no | unknown |
Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.
Read this exercise’s solution
Close S3 only. Keep S1 pending refund confirmation, S2 pending customer notification and S4 pending a usable callback owner/date. One closed plus three open equals four records.
Apply the idea
What record would you expect before changing a pending refund ticket to confirmed?
Save your three-part portfolio
Check all three exercises and include an explanation for each. You may download a portfolio with mismatches for later review; it clearly records which checks passed. Editing an answer or explanation invalidates that exercise’s previous check.
Complete and check all three exercises to prepare your portfolio.
Inspect the portfolio before downloading
Your portfolio will appear here after each exercise has been checked.
Download before leaving. Course answers stay in this page and are cleared on refresh; they are not sent to a server or added to the older course progress tracker.
Source and scope
Occupational task context comes from the O*NET® 31.0 Database, USDOL/ETA, under CC BY 4.0. View the occupation.
Task 2578 · 08/2022 · Keep records of customer interactions or transactions, recording details of inquiries, complaints, or comments, as well as actions taken.
Task 2580 · 08/2022 · Check to ensure that appropriate changes were made to resolve customers' problems.
Skill Workbench selected this context and authored the teaching, examples, practice rules, data and feedback. USDOL/ETA has not approved, endorsed or tested these additions. O*NET® is a trademark of USDOL/ETA. Matching the fixed checks does not certify occupational competence.