Start beside your system, then move in a piece at a time

Start beside ServiceTitan, FieldEdge, BuildOps, Procore, Acumatica or the on-premise ERP you’ve run for years. We built that first step on purpose, we support it fully, and you can stay on it for as long as it suits you. When you’re ready, move the rest of the company onto ServiceProof a piece at a time, at your own pace.

1. Step in beside your system

   Jobs arrive by webhook, API or batch load. Our workflows, rules, events and estimating run on them, and the proof goes back to your system.

2. Move the board

   Book and dispatch the work here, with a lane for every tech and driver and routes in driving order. Your customers and sites come with you.

3. Move estimating and billing

   An accepted quote becomes the invoice, priced from your rate cards, and payments are applied against it here.

4. Move the books

   A general ledger by zone and department, with payroll, payables, commission and sales tax built in.

Nothing is thrown out when you take the next step

• Your workflows, and everything they captured. The procedures you wrote in the first month keep running, and every photo, reading and signature stays on the record.
• Your rules and events. The board you step onto is the same one that has been running your rules all along.
• The app your crews already use. Technicians and drivers have the same app at every step, so nobody in the field starts over.
• Where each job came from. Every job keeps the id it had in your system, so it can always be traced back to the record it started as.
• Your assistant’s reach. Every piece you move is another piece you can run by talking. Run the company from the driver’s seat →

When you move, your sites, customers and route stops come in from a spreadsheet. Every import shows you exactly what it will do before it does any of it, and it never merges two records on its own: an address that already exists comes in as a new record, flagged for a person to decide.

Load sites, then customers, then route stops from CSV, TSV or Excel, and check the file before anything is written.

This is the part that is worth paying for, and it is the part your system of record does not do. The work lands on a board, and the board is not a status display — it is a queue per assignee, and every queue can run its own checklist.

1. The job lands in the right queue without a human

   A dispatch arriving from a national-accounts broker in South Carolina is the Southwest zone’s work, so it lands in that zone’s unassigned column, where that zone’s team picks it up. Geography resolves down to the USPS carrier route — the area one person can actually cover — glued up into territories, most specific wins.

2. Arriving in a queue starts that queue’s workflow

   The technician gets the field checklist. The parts counter gets the parts checklist. The estimator gets the review flow. Same engine, different column.

3. The tech runs it on the app and captures the proof

   Photos, barcode scans, readings, signatures. The answers land in real typed fields you can sort, filter and total — not in a note somebody has to read.

4. Finishing hands the job on

   To Parts, to the estimator, to billing — or to nobody, because “do not transfer” is a real answer rather than the absence of one. And each hand-off starts the next person’s list.

5. Then the tech closes out wherever they normally close out

   In their own field app, on their own screen, exactly as they did last week. We never appear in your org chart.

Here is the shape that makes this work, and it is worth saying plainly because it is not how integrations usually go.

Our dispatch board becomes your event board. A shadow of the board you already have — in lock-step with it, carrying the same jobs, the same people, the same day — except this one is wired for events.

While you step in, your system stays the system of record and keeps doing what it is good at. The shadow does the part it was never built for: reacting.

1. Something happens in your system

   A job is booked, a tech is assigned, a site is added, a visit is rescheduled. However it happened — a dispatcher typing, an EDI feed, a broker’s API, somebody in accounts.

2. We sync it in

   The customer, the site, the job, the visit and who it is on. Enough to act, and not a copy of your whole database — the point is to react, not to become a second source of truth.

3. It lands on the event board and the rules fire

   Zone resolved from the site’s geography. The right queue. The checklist the work actually needs, chosen from what the job is and what is installed there.

4. The work gets run

   By a technician on a phone, by an office person on a screen, by an agent working for one of them, or turn by turn in a text thread for the subcontractor who will never install anything.

5. And it goes back

   The status, the times, the captured answers, the photographs, the document. Into the fields your system already has, so nobody in your office learns anything new.

That loop is the first step. Everything else on this site, from booking the work on this board to running the books, is the rest of the platform, and you step across to it a piece at a time once the loop is running. The whole path →

Queues are columns, and every column can run a procedure. That is what makes a shadow board worth having.

Workflows are the mechanism. Baselines are the point.

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.

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.