Case operations and human decisions

Prioritize by consequence and time

Case priority should reflect potential harm, deadlines, intervention windows, and the evidence available. Arrival order alone can put an urgent case behind routine work. A large amount can matter, but so can a vulnerable customer or an imminent legal deadline.

Define priority rules and permitted overrides. Preserve the original arrival time and every reassignment. Monitor aging by case type and priority. A global average can hide a small set of dangerously old cases. The queue should make the next responsible action visible rather than merely sort records by a score.

Prioritize by consequence and time Prioritize by consequence and time — the flow Follow the sequence. Name the next owner and action. Assess Identify harm and time sensitivity Prioritize Apply the documented queue policy Assign Name the next owner and action — Follow the sequence. Name the next owner and action. Chapter sources · Open image

Prioritize by consequence and time Prioritize by consequence and time — the distinction These concepts answer different questions. Read each definition in the context of the section. Arrival order Cases handled by entry time Risk priority Order reflects consequence and intervention needs — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Prioritize by consequence and time Queue comparison Fictional teaching record. Not simply oldest first. Queue comparison Illustrative data; not a real customer record or a prescribed policy. Case A routine refresh No immediate value movement Case B active transfer concern Short intervention window Priority policy-based Not simply oldest first Not all cases have the same urgency — Fictional teaching record. Not simply oldest first. Chapter sources · Open image

Prioritize by consequence and time Prioritize by consequence and time — control and failure modes Not all cases have the same urgency. The branches show why alternative designs fail. Control design Use consequence and deadline-aware routing. Not all cases have the same urgency. Failure mode 1 Sort only by amount. Other harms and legal clocks can matter. avoid Failure mode 2 Reset age on reassignment. Old work becomes falsely new. avoid Failure mode 3 Monitor only average age. Critical outliers can remain hidden. avoid — Not all cases have the same urgency. The branches show why alternative designs fail. Chapter sources · Open image

Give reviewers the evidence and authority

A reviewer needs the facts relevant to the decision, the applicable policy, and clear authority. Too little information creates guesswork; too much irrelevant data creates distraction and privacy exposure.

Design a case view that shows the timeline, disputed facts, source references, prior actions, and unresolved questions. Separate internal control details from approved customer language. Make escalation available when the reviewer lacks authority or evidence. A queue should not pressure analysts to choose a final label merely because the interface offers no pending state.

A reviewer needs both evidence and a defined authority to act. A case screen can show a payment history while omitting the current restriction or the fact that another team has already intervened. This creates duplicated work and conflicting customer messages. Present the relevant timeline, active controls, pending tasks, and reason for referral in one coherent view, with access limited to the reviewer’s role.

Decision options should have clear consequences. “Close case” can mean that no concern remains, that another team accepted ownership, or that the issue cannot be resolved with available evidence. These outcomes should not share an ambiguous status. A precise closure reason supports quality review and prevents downstream models from learning from a mixture of incompatible labels.

Give reviewers the evidence and authority Give reviewers the evidence and authority — the flow Follow the sequence. Route unresolved or higher-impact cases. Context Show relevant evidence and policy Authority Define permitted decisions Escalation Route unresolved or higher-impact cases — Follow the sequence. Route unresolved or higher-impact cases. Chapter sources · Open image

Give reviewers the evidence and authority Give reviewers the evidence and authority — the distinction These concepts answer different questions. Read each definition in the context of the section. Decision-ready case Relevant facts and authority are available Forced closure Interface demands a result despite missing evidence — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Give reviewers the evidence and authority Reviewer workspace Fictional teaching record. Higher-impact decision route. Reviewer workspace Illustrative data; not a real customer record or a prescribed policy. Evidence payment timeline Relevant facts Authority review only Cannot release restricted funds Escalation designated officer Higher-impact decision route Available buttons should match permitted actions — Fictional teaching record. Higher-impact decision route. Chapter sources · Open image

Give reviewers the evidence and authority Give reviewers the evidence and authority — control and failure modes Available buttons should match permitted actions. The branches show why alternative designs fail. Control design Align the interface with actual authority. Available buttons should match permitted actions. Failure mode 1 Force final closure with incomplete facts. That encourages unsupported conclusions. avoid Failure mode 2 Show every customer document by default. The task may need less data. avoid Failure mode 3 Hide the escalation route. Reviewers may improvise beyond their role. avoid — Available buttons should match permitted actions. The branches show why alternative designs fail. Chapter sources · Open image

Size capacity with queue arithmetic

In a stable system, Little’s Law relates average work in progress, arrival rate, and average time in the system: L equals lambda times W. The units must match, and the relation describes long-run averages under suitable conditions. It does not guarantee a deadline for every case.

If 60 cases arrive per hour and average time in the system is two hours, average work in progress is 120 cases. Service time differs from total elapsed time, which includes waiting. Plan capacity for peaks, complexity, breaks, quality review, and absence rather than assuming every analyst processes cases continuously.

Little’s Law connects average work in progress, arrival rate, and average time in a suitably stable system. It is not a guarantee that staffing equal to average demand will produce a short queue. Variable arrivals, different case durations, breaks, escalation work, and limited specialist capacity can create long waits. Measure the age distribution and service times as well as averages. A small urgent population can miss critical deadlines while the overall average appears healthy.

Size capacity with queue arithmetic Size capacity with queue arithmetic — the flow Follow the sequence. Relate average queue population. Arrivals Measure cases per time unit Time Include waiting and handling Work in progress Relate average queue population — Follow the sequence. Relate average queue population. Chapter sources · Open image

Size capacity with queue arithmetic Size capacity with queue arithmetic — the distinction These concepts answer different questions. Read each definition in the context of the section. Service time Time spent actively handling a case System time Waiting plus handling and other elapsed stages — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Size capacity with queue arithmetic Queue example Fictional teaching record. 60 times 2. Queue example Illustrative data; not a real customer record or a prescribed policy. Arrival rate 60 per hour Stable illustrative average System time 2 hours Average elapsed time Work in progress 120 cases 60 times 2 Capacity math needs a clear time definition — Fictional teaching record. 60 times 2. Chapter sources · Open image

Size capacity with queue arithmetic Size capacity with queue arithmetic — control and failure modes Capacity math needs a clear time definition. The branches show why alternative designs fail. Control design Match units and include waiting time. Capacity math needs a clear time definition. Failure mode 1 Call the average a guaranteed deadline. Individual cases vary. avoid Failure mode 2 Ignore quality review and breaks. That overstates productive capacity. avoid Failure mode 3 Use a stable formula during uncontrolled backlog growth. The assumptions need reassessment. avoid — Capacity math needs a clear time definition. The branches show why alternative designs fail. Chapter sources · Open image

Use quality controls that improve decisions

Quality review should inspect reasoning, evidence, policy application, and customer treatment. Sample across outcomes, reviewers, and risk levels. A checklist can support review, but it should not replace judgment about whether the conclusion follows from the facts.

Track defects by cause. Missing evidence can require a data fix, unclear policy can require editorial work, and inconsistent treatment can require training or supervision. Share feedback in a way that improves the process. Counting errors without giving reviewers a usable correction path creates anxiety more reliably than quality.

Use quality controls that improve decisions Use quality controls that improve decisions — the flow Follow the sequence. Address the specific root cause. Sample Choose representative completed work Assess Review evidence reasoning and treatment Improve Address the specific root cause — Follow the sequence. Address the specific root cause. Chapter sources · Open image

Use quality controls that improve decisions Use quality controls that improve decisions — the distinction These concepts answer different questions. Read each definition in the context of the section. Checklist completion Required boxes were marked Decision quality Conclusion is supported and appropriately executed — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use quality controls that improve decisions Quality review Fictional teaching record. Targeted improvement. Quality review Illustrative data; not a real customer record or a prescribed policy. Defect unsupported closure reason Reasoning issue Cause ambiguous policy example Instruction gap Correction clarified guidance and retest Targeted improvement Complete forms can still contain weak decisions — Fictional teaching record. Targeted improvement. Chapter sources · Open image

Use quality controls that improve decisions — control and failure modes

Control design

Review the reasoning as well as the fields. Complete forms can still contain weak decisions.

Failure mode 1avoid: Sample only easy approvals. Important defects may be missed.
Failure mode 2avoid: Blame analysts for missing source data. The defect may be upstream.
Failure mode 3avoid: Measure quality only by agreement. Reviewers can share the same misunderstanding.

Complete forms can still contain weak decisions. The branches show why alternative designs fail. Chapter sources · Open image

Close the operational loop

Case closure should record the disposition, evidence, actions taken, customer communication, and remaining obligations. A closed investigation can still require a refund, notice, or monitoring update. Model those follow-up tasks explicitly.

Reconcile completed cases with their required downstream actions. Use outcome feedback to improve detection and product design, with appropriate confidentiality controls. A closure label should not become an automatic model truth without considering evidence quality. The case lifecycle ends when the required work is evidenced, not when a reviewer presses close.

Close the operational loop — the flow

DisposeRecord the supported conclusion
ExecuteComplete required follow-up actions
ReconcileVerify no obligation was lost

Follow the sequence. Verify no obligation was lost. Chapter sources · Open image

Close the operational loop — the distinction

Investigation closed: Analytical work reached a conclusion
Workflow complete: Required actions also have evidence

These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Closure reconciliation

Fictional educational excerpt / Not for execution

Closure reconciliation

Illustrative data; not a real customer record or a prescribed policy.

Caseclosed
Investigation complete
Refundnot posted
Financial action pending
Noticequeued
Communication still unproven

A status change does not execute every action

Fictional teaching record. Communication still unproven. Chapter sources · Open image

Close the operational loop — control and failure modes

Control design

Track follow-up obligations beyond case closure. A status change does not execute every action.

Failure mode 1avoid: Use close as a universal completion signal. Refunds and notices can remain.
Failure mode 2avoid: Train directly on every closure label. Quality and meaning vary.
Failure mode 3avoid: Discard the evidence after closure. Later review may need the basis.

A status change does not execute every action. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

Continue with Treasury, liquidity, and settlement operations to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.