Stabilizing a 3-Hour SLA at 15× Volume

Executive Snapshot

1. Executive Summary

In August 2025, one of the company’s clients tightened its service-level agreement for education-document verification from 24 hours per case to 3 hours — at the same moment the operation was absorbing its largest-ever volume surge. Daily arrivals grew from around 100 cases to peaks above 2,000, and the team expanded from about 10 people to 70–80 performers. For two months the department-average turnaround time (TAT) stuck at 6–8 hours. Meetings produced no improvement, because the operating layer around the work — a manually updated sheet, one daytime shift, ad hoc case picking and little visibility of aging work — had not changed.

I analyzed arrival patterns and performer pace, then rebuilt that operating layer: a 30-minute automated queue refresh; oldest-first ordering with a live time-passed clock; rule-based allocation tied to a real roster of shifts, languages, leave and per-person targets; automated alerts listing every case over two hours; staggered shifts across four countries for near-24-hour coverage; and faster performer support through training and an internal knowledge base. The result, as I report it: the department average fell from 6–8 hours to 1.5–2 hours — under the 3-hour target — from the October 2025 go-live, and has held for a full year. No SLA penalties were incurred and the client relationship was retained.

Business Context and Problem Definition

The operation verifies education documents on behalf of clients. Cases arrive through a client API, are checked by performers against specialist rules, and must be completed within a contractual turnaround time. One daily working sheet tracks every open case, its assigned performer and its elapsed time.

That sheet served three clients, but the disruption described here came from one of them: in August 2025 the client replaced its 24-hour SLA with a 3-hour SLA per case. The other two clients kept their existing 24-hour agreements and caused no problems.

The change landed at the worst possible moment for scale. The operation had grown from roughly 10 people handling about 100–120 cases a day to 70–80 performers hired across July and August 2025, at full capacity from mid-August. Monthly inflow settled at a regular 30,000–40,000 cases, with peak days above 1,500–2,000.

For roughly two months — August and September 2025 — the department average stayed at 6–8 hours despite repeated meetings with managers and employees. Those meetings discussed targets; they did not change how work actually flowed. Closing that gap became the project.

The operating scale in numbers

All figures owner-reported or approximate recollections; see Section 8 for evidence status.

Data Discovery and Root-Cause Analysis

I started from the operating data rather than from opinions. Three questions drove the analysis: When do cases actually arrive? How fast do performers complete them? Where do the slowest cases lose their time?

• Arrival pattern. Case volume was not spread evenly across the day. The main wave ran from early afternoon to midnight (13:00–24:00), with a secondary wave around 04:00–05:00. A single shift starting at 08:05 missed most of the demand curve (Figure 1).
• Completion pace. I measured how long performers took per case and separated the fastest and slowest cohorts.
• Slow-case analysis. For the slowest performers I looked deeper: some used inefficient system methods; others were blocked waiting for answers to procedural questions with no quick reference.

The causes grouped into four categories, shown in Figure 2: data and visibility, allocation and prioritization, capacity and scheduling, and performer capability.

Contributing factors and their evidence basis

I used structured cause-and-effect analysis rather than a formal DMAIC project, and no Six Sigma belt is claimed. Causes are called confirmed only where the operating record supports that.

Solution Design and AI-Directed Development

4.1 A queue that refreshes itself (30-minute sync)

I automated the working sheet to pull case data from the API every 30 minutes into that day’s sheet, detect the new sheet created each morning, and sort cases oldest-first. Before automation, updates were manual and ran one to two hours late, so cases appeared on the sheet already an hour or more old. After automation, cases appear one to two minutes after arrival. A Time Passed column — the clock the company and the client measure the SLA against — recalculates every second rather than on refresh.

4.2 Aging cases that announce themselves (alert bot)

The first tool I shipped, while sheet updates were still manual, was a reminder bot. Every 30 minutes a Google Apps Script routine, triggered through a webhook, reads the daily sheet and posts to a Google Chat group containing all performers, leads and managers a single table of every case that has passed two hours: case reference, performer and time passed. Leads no longer hunt for aging work; they act on a specific, current list. Figure 4 shows the format with synthetic data.

4.3 Allocation as a rule-based system

The centerpiece was automatic case allocation. With 70–80 performers across four countries, twelve staggered shifts, languages and specializations, a human cannot allocate fairly every 30 minutes without error. I built an automation-settings sheet that describes every performer the automation may assign to:

Synthetic illustration

Sample roster rows showing how shift, language, target override, working days, leave and special-task fields drive each allocation run. Synthetic illustration — not real staff data.

Every 30 minutes the allocation run takes the new cases, sorts them oldest-first, and for each case finds the least-loaded eligible performer — on shift, present, language-matched, under the hourly cap and under their daily target. The first cap was 3 cases per performer per 30 minutes; after observing real throughput I moved to an hourly cap of 8. The caps keep the distribution equal, keep work waiting for the next shift, and stop a handful of performers absorbing the whole queue while others sit idle. Work is pre-assigned 30 minutes before each shift starts, so nobody opens an empty shift. Figure 3 shows the decision flow.

4.4 Shift redesign around the demand curve

The arrival analysis showed that one shift could never meet a 3-hour SLA: demand peaked just as the day shift was ending. I shared the findings with management and recommended staggered shifts. The result was three shifts per country — 08:00–17:00, 12:00–21:00 and 17:00–02:00 — across four countries (Egypt, Jordan, India and the Philippines): roughly twelve overlapping shifts that cover the clock. Staffing was then balanced to the inflow — fewer people in the quiet mornings, more in the loaded mid and night shifts. The staffing decisions were made jointly with management; the analysis was mine.

4.5 Faster performers

Two fixes targeted the performers themselves. First, training: I trained all performers on faster system methods (observationally around twice as fast as the old routines — an observation, not a formally time-studied figure), and used the TAT and productivity reports to find the slowest performers and retrain them individually. Second, self-service knowledge: I built an internal Google Sites knowledge base holding the operating rules and databases, organized and indexed, and later added a NotebookLM question-and-answer layer grounded in the official documents — a performer asks a question, gets an answer with source links, and stops waiting for a lead.

Related reporting work — quality, productivity and volume dashboards — and an AI Studio document-entry assistant are separate projects documented elsewhere; none of their results is included in this case study’s figures.

Implementation and Project Management

I ran this as an operational project rather than a formal PMO engagement; the phases were short, evidence-driven and shipped in production order.

Risks and how they were handled

Preventive Controls and Continuous Improvement

I did not run a formal Six Sigma project and claim no belt. The preventive thinking, however, is the backbone of the design: every failure mode from the two-month crisis was answered with a control that stops it recurring, rather than with more checking.

What remains open, stated honestly: a formal measurement baseline was not agreed before go-live, and exception logs were not kept systematically. Those appear in the roadmap as improvements — not as achievements claimed here.

Testing and Validation

Before go-live, the automation ran for weeks on a parallel sheet fed by the same data while the manual sheet remained live. That surfaced and fixed the failure modes that matter most:

• Over-allocation: a performer could receive too many cases in one run — fixed with per-run and hourly caps.
• Post-shift assignment: cases could be assigned after a performer’s shift ended — fixed with shift start/end checks.
• Wrong status handling: status mistakes could hide or duplicate work — fixed with status-correction rules.
• Unfinished work at handover: cases left at shift end or before leave — fixed with handover rules.

The alert bot was tested against the daily sheet rotation (a new sheet each morning) and the 30-minute schedule. After go-live, the issues found in real use were fixed in the November–December upgrade window.

Limitation: no formal test-case log was kept. The testing above is described from my account of the work, not from archived test records.

Business Impact and Measurement Limitations

The headline comparison is simple: before the project, the department-average turnaround time sat at 6–8 hours against a 3-hour target; from the October 2025 go-live it has sat at 1.5–2 hours. Figure 6 shows the comparison; the table breaks the claims down by evidence status.

Results table

Validation plan for the missing measurements

The following plan turns owner-reported outcomes into documented ones. None of these rows implies the measurement was already performed.

Lessons Learned and Future Roadmap

What the project taught me

• The fix was a system, not a tool. Fresh data, clear priorities, controlled allocation, matched shifts and faster support had to change together.
• Allocation logic must mirror the real operating environment. Leave, special tasks, shift changes, language rules and demand peaks redefine what “fair” means every day.
• Ship one piece early. The alert bot landed first and delivered value while the larger automation was still being built.
• Measure from day one. A formal baseline and exception log, agreed before go-live, would have made the result auditable rather than owner-reported.

Next steps

• Establish the formal baseline and run the Section 8 validation plan monthly.
• Analyze exceptions systematically to find the next failure modes before they grow.
• Extend the same operating pattern to the other clients’ sheets.
• Keep refining allocation rules as shifts, languages and targets evolve.