Field operations SRE: SLIs, SLOs and incident runbooks for field teams

Software teams figured out something years ago that most field service operations still haven't: you can't manage reliability by feel. You need to define what "working" means in numbers, agree on how much failure is acceptable, and build a rhythm around reviewing what broke and why. That's the core of Site Reliability Engineering (SRE). Born inside data centers, the underlying discipline translates cleanly to trucks, technicians, and dispatch boards — as long as you don't try to copy the software version word for word.

The mistake most people make when they hear "SRE for field service" is treating it as a metrics dashboard project. It isn't. It's an operating philosophy that changes how you argue about priorities, how you decide whether to ship an operational change, and how your team behaves at 6 a.m. when three jobs are already behind. This piece walks through how to translate the SRE toolkit — SLIs, SLOs, error budgets, postmortems, runbooks — into something a field service manager can actually run.

What SRE gets right that field ops usually gets wrong

Most field operations measure outcomes after the fact. You look at last month's first-time-fix rate, notice it dipped, and have a conversation about it that goes nowhere because nobody agreed in advance what "good" was supposed to look like. There's no shared line in the sand.

SRE flips that. You define the target before the period starts, you measure continuously, and — this is the part people skip — you decide ahead of time what happens when you miss. That last part is where the whole system gets its teeth.

A pattern that shows up constantly across service businesses: they have KPIs but no thresholds that trigger action. A dashboard showing FTF sliding from 78% to 71% is just a sad graph unless someone said, "below 74% we freeze new route experiments and pull the RCA team in." Without that pre-committed trigger, the number is decoration.

If you've already built out a metrics layer — and if you have, the field service KPI framework work overlaps heavily here — SRE is the governance layer that sits on top and forces those numbers to mean something operationally.

Defining your field SLIs: pick the signals customers actually feel

An SLI (Service Level Indicator) is a carefully chosen metric that reflects reliability from the customer's point of view. The word "carefully" is doing a lot of work there. Most teams have dozens of metrics; only a handful are true SLIs.

For field operations, two categories matter more than almost anything else:

Truck-roll SLIs. A truck roll is the unit of cost and the unit of customer disruption. Good truck-roll SLIs aren't just "number of truck rolls." They're ratios that expose waste:

1. 1
   Avoidable truck-roll ratio

   rolls that could've been resolved remotely or prevented ÷ total rolls

2. 2
   Repeat-roll ratio

   jobs requiring a second visit within 30 days ÷ total completed jobs

3. 3
   Rolls-per-resolution

   total dispatches ÷ closed tickets (anything above 1.0 is friction)

First-time-fix (FTF) SLIs. FTF is the closest thing field service has to "request succeeded." But raw FTF hides too much. Break it into:

1. 1
   Parts-caused FTF failures ÷ total non-fixes
2. 2
   Skill/diagnosis-caused failures ÷ total non-fixes
3. 3
   Access-caused failures (couldn't get on site, gate locked, no one home) ÷ total non-fixes

That split matters because the cause of the miss tells you which part of the operation to fix. A team sitting at 76% FTF might assume it's a technician-training problem. When they split the SLI, they find roughly 60% of misses are parts-caused — wrong or missing parts on the van. No amount of training moves that number. The fix lives in inventory and kitting, not skills.

The rule for choosing SLIs: if a number improving wouldn't be felt by a customer or wouldn't change a business decision, it's not an SLI. It's a diagnostic metric. Keep those, but don't confuse them with the signals you set targets on.

Setting SLOs that survive contact with reality

An SLO (Service Level Objective) is the target you attach to an SLI. The single biggest error here is setting SLOs at 100% or close to it. In software, chasing the last fraction of reliability costs exponentially more than the previous chunk. In field service the physics are the same — weather, traffic, human no-shows, and part failures mean you will never hit perfect, and pretending otherwise just teaches your team to game the numbers.

A workable structure:

Two things worth calling out. First, each SLO is segmented. A blanket 82% FTF across emergency, planned maintenance, and warranty work is meaningless because those job types have wildly different fix profiles. Second, the SLO runs on a rolling window, not a monthly reset. Monthly resets create an end-of-month scramble and hide within-month volatility.

When tight SLOs are a bad idea

If you're a small shop running fewer than a few hundred jobs a month, ultra-precise SLOs will whipsaw on you. One bad weather week can swing a low-volume percentage by ten points or more. Use wider bands and longer windows — 60 or 90 days — until you have the volume for the math to settle down. Precision without volume is just noise dressed up as rigor.

Error budgets: the concept that actually changes behavior

This is the part that makes SRE more than a reporting exercise. An error budget is the inverse of your SLO. If your appointment-adherence SLO is 94%, your error budget is 6% — that's how much failure you're allowed to spend before you have to change how you operate.

The power move is spending that budget deliberately on operational experiments. Want to test a new same-day routing heuristic? A new subcontractor in a tough territory? A tighter parts-kitting rule? Every one of those risks reliability. The error budget tells you how much risk you can absorb before you have to stop.

How it plays out in practice:

1. 1
   Start the quarter with your budget defined (say, 6% missed windows = roughly X allowed misses at your volume).
2. 2
   Run experiments freely while budget remains. Move fast, try the new routing, pilot the new tech.
3. 3
   Track budget burn weekly. A bad weather stretch that eats half your budget in two weeks becomes visible before it becomes a crisis.
4. 4
   When the budget is exhausted, freeze non-essential changes and shift the team to reliability work — RCA, parts fixes, retraining — until the next window resets.

This kills the two most common dysfunctions at once. It stops the "move fast and break the SLA" crowd from torching customer trust, and it stops the "never change anything" crowd from freezing the operation out of fear. The budget is the referee.

If you're formalizing operational experiments — new automation, ML-driven dispatch, predictive scheduling — the error budget pairs naturally with the guardrails in our guide on governing automation and ML in field operations. You don't roll out an ML routing model without a budget defining how much reliability you're willing to risk during the shadow period.

Incident postmortems that don't turn into blame sessions

Field service has incidents constantly — a missed SLA on a hospital contract, a technician injury, a botched install that damages a customer's property. Most shops "handle" these with a hallway conversation and a stern word to whoever was closest. That fixes nothing because it treats the symptom (a person) instead of the system that let the failure through.

A blameless postmortem assumes the person acted reasonably given the information and tools they had, then asks what in the system made the failure possible. That framing isn't soft — it's the only version that produces changes that stick.

A field-service postmortem template that actually works:

1. 1
   Incident summary — what happened, one paragraph, no jargon
2. 2
   Timeline — timestamped, from first signal to resolution
3. 3
   Customer/safety impact — who was affected and how badly
4. 4
   Contributing factors — plural, always plural; single-cause postmortems are almost always incomplete
5. 5
   What went well — genuinely, because you want to protect the things that worked
6. 6
   Action items — each with an owner, a due date, and a way to verify it actually happened
7. 7
   SLI/SLO impact — how much error budget this incident consumed

The action-items discipline is where most postmortems die. An action item without an owner and a verification method is a wish. "Improve parts stocking" is not an action item. "Add relay X to the HVAC emergency kit SKU by the 15th, verified by cycle count" is.

For anything involving safety or compliance, the postmortem should feed directly into your evidence trail — the safety, compliance and incident management framework we've covered before exists precisely so these postmortems become audit-ready artifacts instead of forgotten Word docs.

Runbooks: turning tribal knowledge into repeatable response

A runbook is a pre-written procedure for a known failure. In software, on-call engineers live by them. In field service, the equivalent is what your dispatcher or on-call lead follows when something predictable goes wrong — a chronic asset trips again, a technician calls in sick with six jobs on the board, a major-account SLA is about to breach.

The value isn't the document itself. It's that the response no longer depends on whoever happens to be on shift. In real operations, the difference between a good and a bad incident outcome is almost always the first 20 minutes — and that's exactly when your least-experienced person might be the one at the console.

A usable runbook has five parts:

1. 1
   Trigger — the exact condition that starts it ("hospital contract job will miss its 2-hour window")
2. 2
   First actions — immediate steps, in order, no interpretation required
3. 3
   Escalation path — who to call, at what point, with what info
4. 4
   Communication script — what to tell the customer and when
5. 5
   Close-out — what to log so the postmortem has data

“

Keep runbooks to one screen and split into two if an appendix is needed.

Keep them short. A runbook nobody can read at speed under pressure is worse than none, because it creates false confidence. One screen. If it needs an appendix, split it into two runbooks.

The review rituals that hold it all together

None of this survives without a rhythm. SRE works because the reviews are scheduled, boring, and non-negotiable — not because someone remembers to check a dashboard when they're already worried.

Three cadences cover most field operations:

1. 1
   Weekly reliability review (30 min). Error budget burn, any incidents, SLO trends. Fast. The point is early warning, not deep analysis.
2. 2
   Monthly deep-dive (60–90 min). SLO performance by segment, postmortem action-item follow-through, recurring contributing factors. This is where patterns across incidents get spotted.
3. 3
   Quarterly SLO recalibration. Are the targets still right? Did volume change? Did a new contract shift the job mix? SLOs that never move are usually being ignored.

A simple diagram like this helps teams visualize where decisions happen and who owns them.

The teams who get lasting value from this versus the ones who quietly abandon it share one trait: they protect the weekly review in the first three months no matter what. It feels like overhead at first. Then a bad trend gets caught two weeks early instead of at month-end, one avoided SLA breach pays for the whole ritual, and suddenly nobody wants to cancel it.

A real scenario

A regional commercial HVAC company — around 22 technicians, roughly 900–1,000 jobs a month — was losing SLA credits on its large facilities contracts and couldn't explain why. FTF sat around 74% and truck rolls felt high, but nobody had a baseline to work from.

They defined three SLIs (FTF split by cause, avoidable truck-roll ratio, and SLA window adherence), set rolling SLOs, and started a weekly 30-minute review. The error-budget framing let them pause an aggressive same-day-slotting experiment that, it turned out, was quietly eating their adherence budget without anyone noticing in real time.

Within a couple of quarters the split-cause FTF data showed most misses were parts-related, which redirected effort into van kitting. FTF moved into the low 80s, avoidable rolls dropped by roughly a quarter, and SLA credit payouts fell to a fraction of what they'd been. Nothing dramatic happened in any single week. The gains came from catching drift early and refusing to run experiments blind.

Who should not do this yet

If your data is a mess — job records incomplete, timestamps unreliable, causes not captured — SLIs built on that foundation will lie to you confidently, which is worse than having no SLIs at all. Fix data capture first.

If you're a two-truck operation, the full ritual stack is overkill too. You can hold the concepts — define good, set a threshold, review what broke — without all the ceremony. And if leadership isn't willing to actually freeze changes when the error budget is blown, don't bother with error budgets. A budget nobody enforces just adds a number to ignore. The whole thing only works if the pre-committed decisions are real.

Bringing it together

SRE for field operations isn't about importing software culture wholesale. It's about stealing the three ideas that made software reliability manageable: define reliability in customer-felt numbers, decide in advance how much failure you'll tolerate, and build a boring, dependable rhythm around learning from what breaks. Truck-roll and FTF become SLIs. Targets become SLOs. Experiments get governed by an error budget instead of gut feel. Incidents produce postmortems and runbooks instead of blame and repeat failures.

Start small. Pick two SLIs, set honest SLOs, run a weekly review for a quarter. The mechanics are simple. The discipline is the hard part — and it's also the entire point.

Start small. Pick two SLIs, set honest SLOs, run a weekly review for a quarter. The mechanics are simple. The discipline is the hard part — and it's also the entire point.