Field operations: five automations that pay, one that never does

Five automations reliably pay for themselves in a field operations business: scheduling against recurring obligations, evidence capture that files itself, report drafting from structured capture, anomaly flagging, and chase sequences with a human escalation point. One does not, at any budget. Fully autonomous customer communication in a trade built on trust costs more than it saves.

An automation pays when it removes a step nobody wanted to do, and stops paying the moment it removes a step somebody was accountable for. That test sorts the list cleanly. Four of the five take clerical work off people. Chasing sits against the boundary, which is why it comes with conditions. The distinction between reading work and deciding work is one we set out in AI for compliance and inspection businesses.

Two builds sit behind everything below: a field operations platform we built for a regulated compliance industry, and a coaching platform where the practitioner is the entire business. No invented savings figures, because we do not know your labour rates. You get the mechanism, and you can run the arithmetic.

1. Scheduling against recurring obligations

Planned maintenance rounds are the easiest money on the list, because a rule generates the work. An asset is due every so many months, and someone in the office turns that into a week of jobs by hand, then does it again every time a customer moves a date.

So the office stops creating jobs and starts approving them. The system projects occurrences forward from the recurrence rule and the office edits the exceptions, so labour falls by roughly the ratio of exceptions to occurrences. You know your exception rate, so you can do this sum today.

Rescheduling is where it bites, and it bit us. Move one occurrence and the original slot reappears on the calendar, so the job renders twice and somebody drives to a site nobody asked them to visit. What fixed it was separating the slot from the date: every booking carries an immutable key for the slot in the series it came from, while its scheduled date stays mutable. Because the slot key never moves, rescheduling cannot resurrect the ghost. We also stopped deleting bookings, only cancelling them, on the grounds that an audit trail is worth more than a tidy table.

2. Evidence capture that files itself

This one pays in a currency most owners undercount: rework avoided. An engineer answers the questions on a tablet and photographs the form, and a structured record exists at the end of the visit rather than the end of the week.

The retyping going away is the visible half. The larger half is that the job stops coming back, because missing photos and readings that never left a pad are what cause a return visit.

The capture has to survive the trip, which is harder than it sounds. On the field platform we built, every engineer action is written as a client-timestamped event into a local queue on the device, and the visit is the replay of its own events. A form cannot be sent before the visit it belongs to has started, or before every photo it references has uploaded. Sync runs in the foreground, because iOS Safari supports none of the background sync APIs, and building on an API half your fleet lacks means half your fleet silently never syncs.

What surprised us was not signal loss but signal that stalls without failing. Requests now carry deadlines, so a hang converts into an error the cache fallback can catch. Three more of these are in the four ways offline apps fail in the field, and most of the systems we build are ones where the record is the deliverable.

3. Report drafting from structured capture

Once capture is structured, the report is a rewriting job. Thirty answers, eleven photos and four readings become the paragraphs a customer reads, with the engineer confirming them.

Who is doing that writing, and when, is the whole argument. On the coaching platform, where the equivalent artefact is a multi-week plan, the framing of the AI feature is that it produces the first 95 per cent in minutes instead of an evening. That names when the work was happening: after hours, unpaid, by the person who least wanted to do it. Ask your engineers what time they finish their paperwork and you have your number.

Two rules keep this on the right side of the line. The draft is presented as a draft, with confirmation recorded against a named person. And where the system cannot support something, it removes it and flags it, and never substitutes a plausible alternative.

It stops paying where reports are mostly numbers with two sentences of commentary, because a template with slots does that job, costs nothing to run and never invents anything. This win scales with how much prose your reports contain, which for some firms is not much.

4. Anomaly flagging against thresholds and history

Cheap to build, and it pays by catching things before it is far too late. A reading gets compared with its threshold and with what the same asset read on previous visits, and anything odd goes to a person. What you are paying for here is the gap between finding a problem now and finding it at an audit, which only you can price.

What the flag keys on matters more than the rule itself. The coaching platform has a check we built for sessions that did not really happen: too short, nobody present, nobody who stayed long enough to count. A flagged session holds the associated payment and notifies the practitioner. The detail that saved us was keying that check on the record's own stamped type rather than on its parent. Parents get deleted, and one legitimate category of session has no participants by construction. Key on what the record already carries and a failed join cannot break it.

Consolidation is the other half. A flagged session sends one notification, not one per affected payment. Same lesson on the video side, where a single flag turns twelve early arrivals into one alert. Alert fatigue kills flagging faster than false positives.

5. Chase sequences with a human escalation point

Reminders for bookings, nudges for overdue paperwork, notices for unpaid invoices. Each is currently a person remembering, which means it happens unevenly and stops entirely in a busy week.

The mechanism is coverage. A person chases the invoices they remember, and a sequence chases all of them. On the field platform the billing runner makes three ordered passes per cycle: issue what is due, send reminders, send overdue notices. It carries a bounded catch-up limit, because a runner that has been down a while will otherwise issue a year of invoices in one morning.

The escalation point is what makes it safe, and it is the decision people skip. On the coaching platform a failed payment sets a status and surfaces on a needs-attention feed for a human to chase, deliberately without a ladder of increasingly stern emails. These relationships survive a phone call and do not always survive a third automated demand.

Keep the boundary explicit. Reminders about facts the customer already agreed to are automation. Messages that negotiate, apologise or explain are not.

The five, compared

The one that never pays

Full autonomous customer communication means the system talking to customers on its own about delays and complaints, with nobody reading it first. The reminder that a visit is booked for Tuesday is fine.

The arithmetic cannot work in a trust-based trade. Your customer chose you over three cheaper quotes because of how somebody handled a phone call, so the relationship is the product. Autonomous messaging saves a modest amount of typing against that, and one badly judged message on the wrong day costs more than a year of the typing. The average message is fine and the tail is catastrophic, and you cannot prompt your way out of a tail.

The best-known example points the same way. Klarna reversed course in May 2025 after claiming its AI assistant did the work of 700 agents. Its chief executive said they had focused too much on efficiency and cost and the result was lower quality (Forbes, 18 May 2025). The reading is not that AI failed at customer service. Klarna kept it on the high-volume front line and brought people back for complex cases. That is a tiering decision, and a firm with a few hundred customers has no high-volume tier. All of your customers are premium tier.

We hold the same line on a platform we build. An autonomous agent there drafts community posts and holds no credentials for the platform it writes for, because rule one is that it never posts. It checks a facts service before claiming the product does anything and skips the thread if it finds no support, since overclaiming is worse than silence.

The assistive version works. Put the model on your side of the conversation, draft the difficult email, and let your ops manager edit it, which captures the time saving without the tail risk. Where a model does reach a customer-facing surface, enforcement belongs in code (guardrails for AI agents).

What owners ask before they buy

Which of the five should we build first?

Whichever removes the most retyping, unless scheduling is still manual, in which case start there because it is cheaper. Evidence capture has the biggest payoff and the longest build, so most firms are better off buying that and building the things around it that are specific to them.

Do we need AI for any of this, or is it just software?

Mostly it is software. Recurrence rules, threshold comparisons and chase sequences are ordinary deterministic code, which is cheaper and easier to audit. The model-shaped jobs are reading unstructured input, such as a photographed form, and turning structured capture into prose.

What about engineers who will not use the app?

Usually a capture problem rather than a people problem. If the app takes longer than paper on a bad connection, they are behaving rationally. Time a full visit on the worst device in your fleet, in a basement, before blaming anyone.