What SLA does a human review step impose on the overall product?

Brindlewood County's permits office uses Codewatch, an assistant that reads a building permit application and drafts a recommend, flag, or deny before a person opens the file. Ottilie Marsh runs the permits program and has to answer for how long a decision actually takes.

How to answer this, stage by stage

Nobody is grading whether you can multiply. They're grading whether you find the term that actually moves, instead of dressing up a guess in decimal points.

Let's learn

Every evening, Brindlewood County's three permit reviewers used to read every application cover to cover by hand, checking it against zoning code themselves. Three to five business days per decision, no matter how straightforward the application was.

Same decision, same reviewers. What changed is how long it waits before a person ever sees it.

Codewatch drafts a recommendation in under a minute now, and on a normal day, the whole thing, application in, decision out, takes under an hour.

At its worst, during the last week of the month, when applications spike ahead of a fee-schedule change, the queue alone stretches the total past four hours, and nobody had written that number down anywhere as the actual SLA.

What I would leave alone: Codewatch's own draft time, under a minute, isn't worth optimizing further. It was never where the delay was hiding, and chasing it would be effort spent on the wrong term of the equation.

The lesson: a human review step's real cost to an SLA isn't how long the review itself takes. It's how long the line in front of the reviewer gets once volume outpaces headcount, and that number moves a lot more than the review ever does.

Now here is the same thing as a story

The short version above is what you'd say defending this number to the county council. Read this one for how the gap actually got found.

Ottilie Marsh has run Brindlewood County's permits program for four years. She's the one who has to explain, in front of the council, why some applicants wait an hour and others wait most of an afternoon for what should be the same kind of decision.

Five parts. Four of them barely move. One of them is the whole story.

For most of the year, Codewatch had made her job easier. Applications that used to take days now cleared same-day, and the council had started pointing to the permits office as a model for the rest of the county's services.

Four boxes barely changed when Codewatch arrived. The middle one is where the whole SLA actually lives.

Then came the last week of a fee-schedule change, when applications nearly doubled as people rushed to file before new rates took effect. Codewatch kept drafting recommendations in under a minute, same as always. But the queue in front of Brindlewood County's three reviewers, whose headcount hadn't grown since the original volume plan was written two years earlier, stretched past four hours by Thursday afternoon.

This is what the same walk looked like on a normal day. Peak week, only one of these four numbers changed.

A local contractor called the office asking why an application that "used to take an hour" was still sitting after lunch. Petra pulled the logs and found the honest answer: nothing about Codewatch or the reviewers had gotten slower. The line of applications waiting for a person had simply gotten longer than anyone had sized for.

Nothing about the AI's own part of the job had changed by a single second. It was the line of applications waiting for a person that grew, and nobody had written that line into the SLA at all.

Not every application needs the same amount of a reviewer's time. The queue math changes depending on which branch it takes.

With headcount sized to the known peak week instead of the average, and the SLA quoted as a range instead of one figure, the same Thursday call from the contractor gets a different answer: still filed after lunch, but now inside a number the office actually promised, instead of one that quietly slipped past a promise nobody had written down.

I built the staffing plan off the number that looked calm on a spreadsheet. It took one fee-change week and one contractor's phone call to see that the number that actually mattered was the one that only shows up the week volume spikes.

BOUND, the arithmetic behind the promiseNot a guess dressed up with decimals. BOUND is what tells you which term of the equation is actually worth watching.

Only the first two of these three actually move the number that matters.

The recap, one line per letter: break it down is the five-part equation, own numbers is each figure traced to a real log, use a range is under an hour normally against four hours at peak, nail the sanity check is beating both the county's target and the old manual baseline, and direction is reviewer headcount, not draft speed, as the lever that actually matters.

And if you want to be sure it really works, try it somewhere elseSame five letters, a prescription prior authorization instead of a building permit. A different queue, the same hidden term.

Bramblecote Pharmacy Group uses ScriptCheck, an assistant that reviews a prior-authorization request against a patient's plan rules and drafts an approve, deny, or escalate before a pharmacist signs off. Folasade Nwachukwu is a pharmacist who reviews ScriptCheck's flagged cases each shift.

Mapped onto BOUND: break it down is the same shape, request intake plus ScriptCheck's draft plus queue wait for a free pharmacist plus the pharmacist's own time plus the pharmacy's own release step. Own numbers looks different here, about 40 requests an hour at a busy pharmacy, two pharmacists on shift, ScriptCheck drafting in about 20 seconds, and roughly 3 minutes of pharmacist review per escalated case. Use a range separates a quiet Tuesday morning, where a request clears in under ten minutes, from a Monday after a holiday, where refill requests pile up and the queue alone can add forty minutes. Nail the sanity check compares that against the pharmacy chain's own promise of same-visit fills for routine prescriptions, which the slow end of the range still meets. Direction is, once again, staffing against volume, not how fast ScriptCheck drafts its recommendation.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "the SLA is a range driven by queue wait, and queue wait is driven by headcount against volume," and stop.
Cost: there's no budget to hire more reviewers before the next peak. Say so honestly, and shift a spare reviewer onto the known peak days instead of spreading headcount evenly across the month.
The model gets better, for real: if Codewatch's draft accuracy improves further, that still doesn't touch the queue term at all, since the draft was never the part of the total that was slow.

Where people run it wrong.
They quote a single average number as the SLA, and the one week it breaks becomes a crisis nobody saw coming.
They spend engineering time speeding up the AI step, because it's the part that's visible and interesting, while the queue quietly does all the damage.
They size headcount off an average from a planning document instead of the known peak the business itself already causes, like a fee change or a holiday rush.

How to use it live. When someone asks what SLA a review step imposes, ask yourself one question first: is the number they want a flat cost, or a queue. If it's a queue, headcount against volume is almost always the number that actually decides it, not how fast any one step runs.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0