Route customer requests and manage a queue without premature closure Skill Workbench · 2026-10-23 · Original fictional teaching material 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. - 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. CASE CONTRACT 1. 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. 2. 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. 3. 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. 4. 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. 1. Separate route, urgency and missing information Name the owner without losing an information hold. 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. Worked example: two fields can be true at once A technical request says service_stopped=yes but has no order reference. It is urgent and also needs information. Record both facts. Do not fabricate a reference to make it look ready, or clear urgency just because the intake is incomplete. 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 YOUR EXERCISE Ready requests routed to technical: __________________ Requests requiring an order reference: __________________ Urgent request IDs: __________________ Number ready to route: __________________ Your explanation: Write a handoff naming the information hold, its next question and how urgency is recorded separately. FEEDBACK AND WORKED 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. Ready requests routed to technical → T2, T5. Both have technical topics and order references. Requests requiring an order reference → T3. T3 lacks the reference and remains an information hold. Urgent request IDs → T2, T5. The service-stopped flag is yes for T2 and T5. Number ready to route → 4. Only T3 lacks the reference; four requests can be routed. TRANSFER QUESTION How would you preserve urgency if the missing-reference record also reported service stopped? 2. Plan a queue within a fixed work window Apply the stated order and whole-task capacity rule. 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. Worked example: stop at a whole-task boundary With 30 minutes available, a 20-minute first task fits. If the next needs 15 minutes, only 10 remain, so stop. Under this unit’s policy you do not start half the second task or skip to a later five-minute task. 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 YOUR EXERCISE Selected ticket IDs: __________________ Remaining open ticket IDs: __________________ Planned work minutes: __________________ Unused minutes: __________________ Next queued ticket after this window: __________________ A: A B: B E: E Your explanation: Write the chosen order, the capacity boundary and the next open ticket. Keep an estimate separate from a service promise. FEEDBACK AND WORKED 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. Selected ticket IDs → C, D. C precedes D by ID at the same priority/time. Their 15+25 minutes fill the window. Remaining open ticket IDs → A, E, B. A, E and B remain; none is closed by being outside the window. Planned work minutes → 40. 15 + 25 = 40. Unused minutes → 0. The selected tasks exactly fill 40 minutes. Next queued ticket after this window → A. The full order is C, D, A, E, B. TRANSFER QUESTION If D’s estimate rises to 30 minutes before work starts, what does the no-skip policy require after selecting C? 3. Close only when the required evidence exists Retain pending actions and customer notifications as visible work. 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. Worked example: confirmed action still needs communication A replacement is confirmed, but informed=no. Under this course’s policy, leave it open as notify-customer. When the notification is recorded, closure can be reviewed; the earlier action confirmation alone was insufficient. 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 YOUR EXERCISE Tickets eligible for closure: __________________ Refund awaiting confirmation: __________________ Confirmed requests needing customer notification: __________________ Tickets missing a usable follow-up owner/date: __________________ Number eligible for closure: __________________ Your explanation: Write the open follow-up list with confirmation, notification and missing-owner actions separately. FEEDBACK AND WORKED 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. Tickets eligible for closure → S3. Only S3 has both confirmed action and customer notification. Refund awaiting confirmation → S1. S1 records submission, not confirmation. Confirmed requests needing customer notification → S2. S2 is confirmed but the customer has not been informed. Tickets missing a usable follow-up owner/date → S4. The callback promise has no usable owner/date. Number eligible for closure → 1. One of four records is closed under this contract. TRANSFER QUESTION What record would you expect before changing a pending refund ticket to confirmed? PORTFOLIO REVIEW Keep all three exercise records and explanations. Fixed checks can be scored; explanations are ungraded. Do not infer occupational certification. SOURCE O*NET 43-4051.00 task 2578 · 08/2022 · Keep records of customer interactions or transactions, recording details of inquiries, complaints, or comments, as well as actions taken. O*NET 43-4051.00 task 2580 · 08/2022 · Check to ensure that appropriate changes were made to resolve customers' problems. https://www.onetonline.org/link/summary/43-4051.00 O*NET 31.0, USDOL/ETA, CC BY 4.0. Skill Workbench authored the teaching and fictional practice; no endorsement.