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.
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.
The board is a work-routing state machine
Most dispatch boards are a status display: coloured 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.
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 rang 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 →
Authoring: madlibs, not a form
A grid of labelled 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.
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.
Where this is pointed next
Two things are in build, and they are written here in future tense on purpose. We demo this in person to people who ask to see it, so a page that sets up a demo to fail is worse than a page that says less.
- Agent-assisted estimating. In build The rule that routes a field finding to the estimator’s column already fires. The review flow that walks a human through building the quote — and the agent that drafts it from what the tech captured, for a human to approve — is what we are building next.
- The truck digest. In build A technician’s day, assembled and pushed to the phone by an MCP-connected agent: what is on, what changed, what needs a part, what is likely to run long.