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.
Start with the flow the rest of it exists for: Found on
PM. A technician notices work on a maintenance visit, and six
steps later the customer has said yes, the invoice is paid and the
technician has been paid for noticing.
Then the machinery under every flow, 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.
Balance to Baseline, running on one job
Found on PM, start to finish
Every field service company loses money between “the tech noticed
something” and “the customer got a quote”. This flow
closes that gap, and it is not a feature tour: it is
Balance to Baseline on one job. The
business sets a standard, the technician meets it, the money follows
— and the week comes back to the standard.
The six steps, and beside them the five pillars and the loop they run
through. Bid overlaps Business on purpose: the
technician is executing one job and selling the next.
The business sets it on the technician’s scorecard — four
finds a week is the example — and each technician can open their
own card and see it, with its weight beside it.
On the visit the agreement generated: photos, what is failing, what it
will take, a rough price on the phone — and the find is stamped
with their name the moment they raise it.
The find is its own job in the Estimate queue, and a rule you set once,
as data, starts the estimator’s review on it. Nobody had to route
it or remember it.
Earned on that paid invoice by the finder, the estimator and the crew,
each on their own plan. And the week’s finds are scored against
the baseline, which is kept or adjusted.
Every step is a number
Each one is counted from the job’s own origin and credited to
whoever found it — finds, approvals, the value won, invoiced, paid
and collected, one measure per step, for any week a manager asks about.
And each is a documented capability, so an agent can walk the chain as
well as a person.
The standard that is easy to ask for and almost impossible to
measure: every technician raises new work they spotted while
out on their maintenance visits. Not “do the PM and
leave” — walk the building like you work there.
Here it is a real baseline, not a slogan. The business sets it on the
Found on PM measure — for a crew, or for one person
— and four a week is the example, not a number we ship. It sits
on the technician’s scorecard with its weight printed beside it,
and each technician can open their own card and see it.
A week with none is a conversation, never an automatic mark against
anybody. Some buildings really are fine.
The visit was made by the service agreement — a quarterly
rooftop inspection, generated inside a window rather than pinned to a
date. Recurring commitments →
On site, on their own open visit, the tech taps Found
work and runs the Found on PM checklist: what kind of find it
is — failed now, failing in weeks not months, a code or safety
issue, an improvement the customer would want — a wide photo and
a close one, what is failing and what it will take, a rough material
cost, the crew hours, and whether the site contact saw it.
Raising it makes a new job for the same site and payer, and
stamps the technician as its finder right then. Nothing
afterwards works out who found it — by the time the money
arrives, three other people have touched the job, and none of them
noticed it.
Then they can price it rough, on the phone, standing where they found
it: parts, labor, photos, a recording or a supplier’s PDF. The
office refines it and sends it.
This is where two pillars overlap. The technician is executing one job
and selling the next — the program’s own rule for a tech
with time left on a visit: use it, and generate the next quote.
The technician hour problem →
Price it rough — the office refines it and sends it.
Found on PM in the builder: seven steps, required where it matters, written the way a technician talks.
The new job lands in the zone’s Estimate queue — a column on
the board like any technician’s, with a queue’s name at the
top instead of a person’s.
Arriving in that column is an event. A rule bound to it once, as
data — when work lands in the Estimate queue, start
Estimate Review — starts the estimator’s checklist on the job.
Nobody routed it, nobody had to remember, and it does not depend on the
tech texting somebody.
Its steps open the pages where the work is really done — price the
lines, add what technicians forget (the helper, the permit), send it
— and each one takes back done or couldn’t
in the side panel the estimator works beside.
How rules and events work →
Estimate Review is a column on the board, beside Parts Ordered and the technicians.
The estimator opens the job’s quote with the technician’s
lines already on it, the photographs, and every answer anybody ever
captured at that site.
Price levels and rate cards do the pricing, and good, better and best go
out as real alternatives, each with its own total. Sent as a PDF under
your letterhead and stored at the moment it goes
— the file you sent is the record. The job steps onto your
waiting-on-the-customer column, if you keep one, and every time the
customer opens the link is counted.
The yes names the option they took, and moves the job
itself — to the zone’s Unassigned column for a
dispatcher. Same job, same number. A no, on a job that only ever existed
as an estimate, cancels it.
Estimates, quotes and invoices →
The estimator’s bench: the lines, the options, and what it comes to.
Make the PDF and send it. The file sent is the record.
A dispatcher schedules it — often to a different technician, who
does the work. The finder’s name stays on the job’s origin
the whole way.
The accepted quote becomes the invoice: only the
lines they accepted, at the prices they agreed, never retyped.
Payments — checks, cards, transfers, part payments — are
applied against it, and the one that brings the balance to zero marks
it paid in full. That moment is an event too. A
bounced check puts the balance back.
Paid in full is when commission is earned — by
the technician who found it, the estimator
who quoted it (at a lesser rate when a technician found the
work), and the crew who did it, split evenly.
Each on their own plan, labor and parts at their own percentages. It
lands on the next check through payroll, and on the
technician’s paycard on their own phone, invoice by invoice:
you found it.Commission, earned from baselines →
The commission is earned on the paid invoice, not on the scorecard.
The scorecard is how the find rate is judged.
This week so far, and the commission on this check.
Who earned what, on which paid invoice, as finder, estimator or crew — and the plan that set the rate.
And the week comes back to the baseline
The technician’s card counts every find in the week it was raised,
then the approvals, the invoiced and the paid in the weeks they happened
— all credited to the finder, so a slow customer never costs anybody
the credit for noticing.
Four finds against a baseline of four — met. One approval against two — under. The measures with nothing behind them this week are left out, not scored as zero.
The technician sees it on their own phone as the week goes.
My Numbers →
Once the week closes it is scored by itself, overnight, and calibration
says whether four is still the right number — with the target the
results would support. Then comes the part no software should do on its
own: keep the baseline at four, or change it, with a
reason in your own words — a number on the card, not a release.
Set the baseline, execute to it, collect the data, analyze the
variance, adjust, repeat.
The loop that never stops →
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 whole procedure in one list. Each step says what it captures and whether the run may pass without it.
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.
Pick the procedure, anchor it to the visit. From here the run knows the job, the site, the equipment and who is paying.
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 same run, on the phone that is actually in the mechanical room.
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 the office will be asked about later.
A choice that changes the rest of the run.
The serial, off the plate, into a field.
And room to say it in their own words.
Required photographs are a condition of the step, not a reminder. The shots can be named — driver side, passenger side, load area — so the one that is missing is obvious.
A number with its own range, checked while the person who can go and look again is still standing there.
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.
Every step and its answer, in order. If something is wrong, it is wrong in front of the person who can fix it.
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.
New commercial customer onboarding, as an office SOP. The eleven things your best dispatcher knows, written where the next person can read them.
Worth saying plainly, because software that watches people is a real
category and this is not it.
It is not a league table. Everyone sees their own card and their own numbers, nobody is ranked against their colleagues, and the one board the whole shop sees counts good catches made, never mistakes.
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.
