Stage 01
Intake
The engineer's email arrives as-is: prose, parcel lists, KMZ files, plan sets, photos. Nothing is re-keyed by hand.
Outcomes Automation / Casework
A year of utility paperwork, run as a system.
A small land-services firm under a standing MSA with a major investor-owned electric utility. Engineer's email in, priced scope of work on the utility's template back, for over a year, through engineer turnover, rate-sheet changes, and a full template revision. Volume has grown from a few documents a week to sixteen to twenty now.
The client and history are real · Identifying content reconstructed under NDA
Five stages, one human sign-off, no exceptions
Stage 02
Extraction
Parcels, tasks, locations, engineer, due date, and rate references pulled into structured project data. Site photos and satellite imagery get reviewed the way an estimator standing at the site would.
Stage 03
Pricing
Every task priced from the client's current rate sheet, the one in force this week, not the one from intake day.
Stage 04
Assembly
The document is built on the utility's own Word template, section by required section, formatted to submit.
Stage 05
Audit & sign-off
Line-by-line verification against the source email, checklist attached, and a human reviewer signs before anything ships. Zero exceptions to date.
Exhibit A: what arrives, and what ships the same day
Reconstructed with a fictional project
What arrives
From: field engineer
Subj: reconductor project, 3 parcels, need ISOW
"Two easements to review, one new acquisition. Landowner on parcel 2 runs cattle, gates have to stay closed, he was burned last time. Survey crews want access letters first. Rate sheet rev. C applies. Can we have it this week?"
What ships, same day
Individual Scope of Work
Survey permission letters, 3 parcelspriced
Easement review ×2priced
New acquisition, parcel 2priced
Livestock/gate protocol, written into scopeincluded
Verification checklist, each line → sourceattached
Audited ✓ Human-reviewed
The detail that matters: the cattle-and-gates concern in the engineer's prose became scoped, priced language in the document rather than a lost sentence in an inbox, which is what "audited against the source" buys.
Verification checklist, attached to every document
[✓]Every task traced to a sentence in the source email
[✓]Rates checked against the current sheet revision
[✓]All required template sections present and populated
[✓]Parcel counts and locations match the intake
[✓]Field constraints written into scope language
[✓]Human reviewer sign-off, required to ship
Exhibit B: what a year of production threw at it
Month 1
First live documents ship against real deadlines.
Rate change
The utility revises its rate sheet. The pipeline reprices from the new revision, mid-stream.
Turnover
Engineers rotate; new senders, new writing styles. Intake keeps parsing.
Template rev.
A full template revision from the client. Documents ship on the new format the same week.
Month 12+
Still running, now at sixteen to twenty documents a week. If the documents didn't clear utility review, the work would have stopped.
| By hand, before | Through the pipeline | |
|---|---|---|
| Turnaround | Days, fit around fieldwork | Same-day target from intake email |
| Formatting | Varies by whoever wrote it | One standard, the client's template, every time |
| Pricing | Whichever rate sheet was remembered | The current revision, checked at build time |
| Verification | A re-read, if there was time | Line-by-line audit, checklist attached, human sign-off |
| Field hours | Lost to desk work at field rates | Kept in the field, where they bill |
What I won't print here: the client's name, the utility's name, or any real document. My agreements keep them off the page, and yours would too. Get me on a call with references and I can be specific.
Exhibit C: four from the production log
Real cases. Identifying details removed, numbers rounded.
The two-option scope
An intake where the landowner count could land anywhere from one to ten. The ISOW shipped as two priced options: a worst-case build on the landowner basis, and a leaner build from the engineer's own task list, with the difference explained. The client read both and funded the worst case.
The change order with no parent scope
A request to amend legacy program work that predated the desk, so there was no original ISOW to amend. The change order anchored to the purchase order instead, with the funding history written out line by line so review could follow the math without a phone call.
The one that never left the building
A change order got priced against the wrong anchor document. The audit caught it the same day; it was rebuilt against the correct purchase-order change and submitted right. The two builds differed by about $3,700, which is what that checklist is for.
The work order number that didn't exist
The engineer's email carried an eight-digit work order number in a system that uses nine. One digit had been dropped somewhere upstream. Flagged at intake, confirmed with the sender, corrected before anything was built on it.
Judge it on your own work, not this page.
Send one live project: the engineer's email, your client's template, the current rate sheet. The first document comes back free.