The office half — and it is the half that scales you
The office runs on SOPs
Every competitor has a field app. Nobody automates the office — and the office is where a shop stops scaling. You can add trucks. Adding a dispatcher as good as the one you have is the hard part.
So this half of the product does one thing: it turns how your business actually runs into standard operating procedures that are current, because they are the same object your staff walk through to do the work.
And if you want a method for building them rather than a blank page, that is a whole program in its own right — five pillars, a baseline on every process, and the people who do the work writing the procedures they own. Balance to Baseline →
This is a module. It runs beside the system you already have — the work comes in, the procedures run, the results go back. You do not have to move your customers, your history or your accounting to get it.
The SOP writes itself
Every shop over about six trucks has the same problem, and it is not a software problem. Your best dispatcher knows the eleven things that have to happen when a new commercial customer signs. Nobody else knows all eleven. The list lives in her head, and it leaves with her.
The usual fix is a binder. The binder is out of date the month it is written, because writing it is a project and doing the job is a Tuesday.
| What the office actually deals with | What a workflow does about it |
|---|---|
| The new CSR misses step seven. Not because she is careless — because nobody ever wrote down that there was a step seven. | The step is on the screen, in order, with the field it needs to fill. She cannot get to step eight without it. |
| Everyone does intake slightly differently, so the reporting is mush and nobody can tell which version is right. | One published SOP, one shape of record. Versioned, so last year’s job was run against last year’s rules and still reads correctly. |
| The audit log says “Dave changed the tax code at 14:02” and nobody alive knows why. | It says “under run 4471, step 3 of New Commercial Customer.” The why is structural instead of remembered. |
| Training a new hire means sitting next to somebody for three weeks, which costs you two people instead of one. | The checklist is the training. She is useful on day one and the supervision is built into the work rather than bolted beside it. |
| The SOP you wrote for CBRE does not fit the dive bar, so you end up with two documents that drift apart. | One workflow, scoped differently. The difference between two customers is data — a condition, a branch, a custom field — never a second version to maintain. |
The library. Field procedures and office procedures, same engine, same list — nothing affects live work until a version is published.
Watch one go all the way around — authored, published, and walked on a phone →
The board is a work-routing state machine
Most dispatch boards are a status display: colored boxes telling you what already happened. Ours is a set of queues that do something when work lands in them.
- Unlimited named boards. A board is a set of filters saved under a name — Service, Repairs, Inspections, Northwest Team. Charlie’s runs three off one dataset. Build a board for a team, a department, a zone or a week, and it costs nothing to make another.
- Columns are assignees, and an assignee does not have to be a person. Rudy is a column. So are Parts Ordered, Estimate, Subcontractor, Long Lead Time and Shipping Direct. One assignment mechanism, one history, and an admin can add a column without anybody writing code.
- Unassigned is a real state with its own column per team. That is what makes it an inbox somebody works rather than a hole work falls into. Brokered jobs that arrive over the API land there automatically, in the right zone, with no human triage.
- The job persists; the assignee changes. A job’s whole life reads back as the sequence of people and queues it passed through, with the time it spent in each.
One saved board, one zone lane, a column per assignee. The unassigned inbox is a queue somebody works, not a hole work falls into.
The same saved-filter idea works on geography rather than columns: pick a dataset, narrow it until it says something, save it as a named board. Map boards →
Every column is somebody’s queue
This is the single idea that makes the office half work, and it is worth reading twice: because a column is an assignee rather than a status, a job sitting in it can have a checklist running on it.
Parts Ordered, Estimate Review and Transfer are columns exactly like Rudy and Eric are columns. One assignment mechanism, one history — and each of those queues can carry its own checklist.
A job hands off, and the hand-off starts the next list
The technician finishes and the job transfers to Parts. The parts counter’s workflow starts on it — check stock, raise the PO, chase the vendor, receive it. The parts land and it hands back to a technician, whose field workflow resumes where it left off.
Nobody called anybody. Nobody remembered. The job moved and the move started the work.
- Where a completed job transfers to is configured, not hard-coded — and do not transfer is a real answer rather than the absence of one, so a finished job never falls into a default column because nobody said otherwise.
- The workflow decides whether the destination is fixed or a choice. Fixed means it goes there and the handset is told. A choice means the workflow supplies the candidate list and the tech picks — so “this needs a second visit, send it back to Schedule” reaches the system without anybody routing around the SOP.
- Each hand-off is recorded as its own visit, so the timeline is the job’s history rather than a note somebody typed.
The parts leg of the same job, captured at the counter.
Recurring work, PM or route
A quarterly rooftop inspection and a twice-weekly bank deposit run are the same object: a promise to show up at a place, on a cadence, and do a defined thing. They differ in frequency and in what gets delivered — not in kind. So there is one recurring commitment, authored one way, and it covers preventive maintenance, monitoring, commercial agreements and delivery routes alike.
A window, not a date
Every occurrence carries earliest, target and due-by. That is not a nicety — it is why the schedule survives a heat wave. PM work is what gets pushed when emergency work lands, so the model knows from the first table what may move and how far.
Bulk rescheduling is cheap
A freeze week does not mean a dispatcher dragging sixty jobs one at a time. Push the ones that can move, and the system tells you which ones cannot.
It warns you before a breach
Not after. If pushing this job puts you outside what you promised, you find out while you can still decide something.
And a breach is recorded
On the record, at the time, with what happened. That is the argument you need in the meeting a year later — and it either got written down when it happened or it did not.
What the commitment book owes, with the room left on every promise. A maintenance round, an inspection cycle and a twice-weekly delivery route are all in one list, because they are one object.
Moving a freeze week’s worth of work. It costs the move out first — six would breach — and it will not let the push through without a reason, because the sentence somebody types is what the argument turns on a year later, not the flag.
A recurring commitment can pin the same crew or the same driver, because on a route the driver knowing the stops is the service. How that plays out for a courier →
A commitment is a promise and it generates work. The day’s execution plan — this driver, these stops, in this order — is a different object, and conflating the two is why some software cannot answer either question. The route plan →
Authoring: madlibs, not a form
A grid of labeled boxes is a good way to store a record and a poor way to check one. So records are built as a sentence you fill in — which reads back as something a human can actually verify, and which works on a phone in a way a twenty-field form never will.
Authoring the other half: steps in order, what each one captures, which are required, and where a choice branches the run.
And the workflow drives the screen
A step does not just say “get the tax status.” It can open the screen that captures it, with the right record already loaded, and take the ok-or-fail back when it is done. That is what makes a checklist stop people missing details rather than merely recording that they did.
Because of that, a step declares the capability it needs, not the screen it wants — “set the tax status” is the requirement, and a madlib panel, an API call and an agent querying a state portal first are three ways of satisfying it. One workflow runs in the office, in the field, and headless.
The people on every record
The facilities coordinator at CBRE. The building engineer with the roof key. The inside sales rep at the supply house. Who to call if a technician gets hurt. The office needs every one of them at 4:30 on a Friday — and in most systems they are a notes field and three phone columns.
Here they are people, kept on the record they belong to: a customer, a site, a supplier and each of its branches, one of your own employees. Each person has as many ways to reach them as they really have, with the first choice marked, and one person can be the main contact.
Added by sentence, read back before it saves
Add Sam Okafor, Inside Sales, as our sales rep for Carrier Enterprise, reached by a mobile on 512 555 0133. Fill in the blanks, and the whole thing is read back to you as a sentence before anything is saved — the same madlib as the rest of the office, above.
Whether they said you may text them is on the record
Check the box only if they said yes, and the yes is stamped with when it was given. It covers the texts about their work — confirmations, the technician on the way — and never marketing, which is a separate yes. Change the number and the yes does not follow it onto somebody else’s phone.
The building’s people stay with the building
The engineer at a site stays with the site when the payer changes. The people who answer for an account — billing, the decision maker — stay with the customer, at every site it backs.
Somebody who leaves stays on file
Uncheck them when they leave: they are marked not current, and they stay on file rather than disappearing. Remove is for a contact that was never right — a duplicate, the wrong person, a typo that became a row.
A supplier’s people, branch by branch. The office screen, on a phone.
Read back first — and it says out loud that nobody has said yes to texts.
A customer’s people: the main contact, what she is to the account, the number to try first, that she said yes to texts, and the address the invoices go to.
Augment the office. Don’t replace it.
Every competitor sells a field app. Nobody automates the plumbing office — and the office is where a shop stops scaling. You can add trucks. Adding a dispatcher who is as good as the one you have is the hard part.
So the promise is deliberately not “replace your people.” It is train agents to do the repeatable tasks that support the staff you already have, and do the volume you could not do before.
Why an agent can actually do it here
Not because we bolted a chat box on. Because of how the platform is built: every capability is written once and exposed on every door at the same time — the screen, a REST route, and an MCP tool. A capability that exists on only one of them fails the build.
So an agent working a checklist is doing exactly what a person on a screen does, through exactly the same executor, with the same permissions, the same locks and the same audit trail. It is not a side door. There is no side door.
- The agent hits a step it cannot satisfy, a human picks it up mid-run.
- A human hits a step that needs a lookup somewhere else, an agent can take it.
- Either way the run records what happened, who did it, and under which step.
Shipping today: ask about a job and get an answer, not a document.
Estimating is where a shop stops scaling
Every growing shop hits the same wall, and it is not technicians. It is that the revenue waits on one person being free. Work gets found in the field, and then it sits — in a text message, on a sticky note, in an estimator’s afternoon that already had eleven other things in it.
So this is the office’s side of the flow the whole product is built around, Found on PM. A technician has already found the work on a maintenance visit and priced it rough on the phone, photographs and all. Here is what happens next — and nobody has to chase any of it.
-
The estimator’s queue lights up
The find arrives as its own job 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. A rule you set once, as data, starts the estimator’s review on it. Nobody routed it, nobody had to remember, and it never depended on a text message.
-
Review it, and price it from your rate cards
The quote opens with the technician’s lines already on it, their photographs, and every answer anybody has ever captured at that site. The customer’s own price level, your rate cards and your markup bands do the pricing, while the review’s checklist runs beside it — price the lines, add what technicians forget, the helper and the permit. Good, better and best go out as real alternatives, each with its own total.
-
Send it under your letterhead
One press makes the PDF and keeps it; then it is emailed to whoever decides. Your logo, your address and the licenses you have to show sit at the top, and the file you sent is the record — it is never re-drawn. The job steps onto your waiting-on-the-customer column, if you keep one.
-
The customer approves
The yes is recorded with the option they took, and only that option’s lines go forward. A no is kept with its reason from your own list — and on a job that only ever existed as an estimate, it cancels the job, so nothing sits in a queue waiting for work nobody ordered.
-
It lands with the dispatcher
The yes moves the job itself to the zone’s Unassigned column, for a dispatcher to schedule. Same job, same number, the finder’s name still on it — and when the work is done, the accepted quote becomes the invoice with only the lines they took, never retyped.
That is what scaling with the crew you already have means. Not working people harder. Moving the chase out of somebody’s head and into the work itself — a queue instead of a text message, a checklist instead of a habit, the site’s own history instead of somebody’s memory.
What you get at the end of it
SOPs are the mechanism. Baselines are the point. Writing procedures down is worth something on its own; writing them down and then measuring against them is what actually scales a shop.
Once the procedures are running, every one of them is producing the same thing as a by-product: a number. How long that job actually took against what it was budgeted. How long the quote sat. How often the step really got done. You did not have to collect any of it — it fell out of the work.
A standard on every activity
Not a stretch target. The attainable number that means the business is running properly — with a tolerance band, because beating a budget by forty percent is not excellence, it is your book being wrong.
A dashboard per pillar, per zone
Plan, Sell, Execute, Collect, Improve. Attainment by team and by branch, so a Monday meeting runs on numbers instead of on whoever speaks loudest.
A scorecard everybody can see — their own
The eight or nine numbers that describe your job, live, at any time. That is what makes it feel fair rather than feel like surveillance. You cannot hit a target you cannot see.
And the standards say when they are wrong
A baseline almost everyone clears is too loose and is costing you on every quote. One almost nobody clears is unrealistic and is costing you people. The loop measures every closed week and month by itself, and says which is which, with the target the results would support — and a person decides. The loop →
In build The pillar dashboards are being built now. The measurement under them already runs by itself, and the operational data it reads is captured on every job that runs through the platform — which is the part that cannot be backfilled, and the reason starting now is worth more than starting when the dashboard is finished.