The whole loop, start to finish

One checklist, walked

This is the product. Everything else on this site — the board, the rules, the field app, the map — exists to put the right checklist in front of the right person at the right moment.

So here is that loop, end to end, with nothing skipped: somebody writes down the job, publishes it, and somebody else walks it on a phone in a mechanical room. What comes back out is the record of what happened, in real fields, in order, with the photographs attached.

Write down the job you already do

A water heater changeout has an order to it. Kill the gas. Photograph the old unit before you touch it. Get the serial off the data plate. Check whether it is gas or electric, because the next six steps are different either way. Pressure test. Photograph the finished install. Get a signature.

Your best installer does all of that without thinking. The new one does about seven of them. The difference between those two people is not talent — it is a list, and the list has never been written down because writing it down is a project and doing the job is a Tuesday.

The workflow builder showing a water heater changeout procedure in full: every step in order, each with the kind of answer it captures and whether it is required.

A step is a question with a shape. A photograph. A serial. A number with a legal range. A yes or no. A choice that changes what comes next. The shape is chosen when the procedure is written, so nobody is typing a pressure reading into a comment box.
Required is enforced where it matters — at the moment of capture, on the handset, not by somebody in the office noticing three days later that a photo is missing.
Nobody writes code to add one. The builder is a screen. Everything it does is also a documented API call, which is how an agent can draft a starter procedure for a shop that has none.

Publishing is what makes it a standard

Editing a procedure does not change a single job that is in flight. Publishing does, and it publishes a version.

Last year’s job still reads correctly

A run is pinned to the version it started on. When you tighten the procedure in March, the January jobs do not retroactively become non-compliant against a rule that did not exist when they were worked.

Drafting is safe

You can rework a procedure all week with live work running on the published one. Nothing you type reaches a technician until you say so.

And it reads back as a document

The same object your staff walk through is the thing you hand a new hire, an auditor or a customer who asks how you do it. That is why the SOP can be current, and a binder never is.

A binder is out of date the month it is written. A published procedure is out of date the moment somebody edits it — and that is the moment you find out, because the edit is the same act as the update.

Then somebody walks it

A run is not a form floating on its own. It is anchored — to this visit, at this site, on this job, for this customer. That is what lets the checklist know where it is, and it is why the record it produces is worth anything afterwards.

Starting a workflow run: choosing a published procedure and anchoring it to the visit it will be the proof of.

Step one, before anything is touched

On a lot of jobs step one is the safety brief, and it is first for the same reason it is first in real life. The run does not get to step two until step one is answered.

A technician who loses signal in a basement keeps working — the screen still has the job on it. How it behaves with no signal →

One step at a time, in the order the procedure sets.
Where it was left off is recorded, so a second person can pick it up.
Every answer carries who gave it and when, without anybody typing that.

The rest of the technician’s day →

A workflow step running on a phone, capturing an equipment serial number straight off the data plate.

What a step is allowed to ask for

This is where a checklist app and a piece of paper stop being the same thing. The answer lands in a real field with a real type — so it can be searched, compared against last year, trended across forty units, and exported to whatever you report in.

A yes-or-no workflow step on a phone, with both answers as full-width buttons. — A yes or no the office will be asked about later.

A choice step on a phone that branches the remainder of the procedure depending on which option is picked. — A choice that changes the rest of the run.

Capturing a serial number off the data plate as a typed answer rather than as free text in a note. — The serial, off the plate, into a field.

A long-form step where the technician writes the story of the visit in their own words. — And room to say it in their own words.

A workflow step that will not pass until the required photographs have been captured, with the outstanding shots named.

A numeric workflow step with a legal range enforced as the number is entered.

Where you compress a photo decides whether it is evidence Shrink it on the handset and the camera’s own metadata — time, place, device — is gone before anything of ours has seen it, so “we captured it” quietly becomes “the phone told us.” The original crosses the wire, the server reads the metadata and fingerprints the original bytes, and the fingerprint is kept forever even if you choose not to keep the full-size image. Why a courier cares about that →

The story of the visit

At the end, the run reads back as one thing: what was asked, what was answered, what was photographed, in order, with the times. It is read back before anybody signs it off, on site, while the person who knows is still there.

That record is the thing you get paid against and the thing you are defended by. It is also the reason a callback is not a rediscovery: the next technician opens the site and reads what the last one actually found, rather than a note that says “PM done.”

Answers are stored as fields, so “every unit whose suction pressure moved more than 15% since last year” is a query rather than an afternoon.
The run says which published version it was walked against, so an argument about the rules has an answer.
What a run still owes — a deferred photograph, an unanswered required step — is tracked as a debt, and the job cannot be closed around it.

The same engine, one floor up

Nothing about any of this is specific to a technician. The same builder, the same runner and the same record serve new commercial customer onboarding, the parts counter, the billing clerk and the dispatcher.

One engine, two outputs. In the field a run produces proof. In the office it produces conformance — the step was taken, in order, by the right role. Same object; the difference is who is walking it and what they are walking it for.

An office standard operating procedure in the builder: new commercial customer onboarding, step by step.

The office half → What starts a checklist →

What this is not

Worth saying plainly, because software that watches people is a real category and this is not it.

It is not a scorecard. There is no ranking, no league table and no productivity grade.
It is not a tracker. The point of a timestamp is the interval it measures — travel, waiting to get in, working — so you can quote a job honestly. It is not there to tell you where somebody had lunch.
It is not a script somebody reads at the customer. The whole of the last section is the technician saying what they found, in their own words.

It is the machinery that runs your procedure. The same job, done the same way, every time — and every answer captured once, where the next person can find it. Consistency is something you give people. It is not something you do to them.

And when an office rule and a technician standing in front of the work disagree, the technician wins. A rule that stops somebody recording what they can see does not change what happened — it only stops you knowing about it, and then the record you sell as proof has a hole in it nobody can see.

See it on your own data What a run costs →