Augment — the low-risk way in

You don’t have to replace anything to start

Most field service software sells a replacement: rip out what you have, migrate everything, retrain everybody, and hope. That is a twelve-month decision, which is why most of those deals never close — and it is not the one we are asking you to make.

Keep your system of record. We take the work in, put it on a board where your rules can reach it, run your checklists on our app, and send the proof back out. One crew, one workflow, one month is a real way to start.

Keep the system you already bought

ServiceTitan. FieldEdge. Procore. Acumatica. HouseCall Pro. BuildOps. dESCO ESC. Whatever you run, it stays the system of record. It holds your customers, your invoices and your money, and we are not asking you to move any of it.

We are deliberately not the source of truth. That is a design decision, not a limitation. It is what lets you start on a Tuesday with one crew instead of starting next year with the whole company.

🔒

Nobody in the office relearns anything

Your CSRs, your billing clerk and your controller keep the screens they already know. The change lands on the field crew and on the workflow you choose to run — nowhere else.

📦

No migration

Twenty years of history stays where it is, in the system that can already read it. We are not asking you to carry it, and we are not asking you to leave it behind either.

✂

You can stop at the end of any month

No term. Nothing of yours is trapped here, because the thing that runs your business never moved in the first place.

Buy only the workflow seats for your commercial electrical crews and keep Procore. Run Acumatica and our mobile app for your locksmith shops. That is a supported way to own this product, not a workaround.

“We already bought an FSM with a mobile app”

That is the fair objection, and it comes up in the first ten minutes, so here is the answer plainly. Good — keep it. This does not replace your dispatch board or your app. It is the layer that makes the work run the same way every time and comes back with the proof, and it feeds the system you already pay for.

The slice we take is the slice a job needs. It is enriched in the field and handed straight back. Nobody is migrating anything — in and out like a river.

Getting the work in

Four doors, and most shops use more than one. The job of all of them is the same: get today’s work onto a board where your rules can reach it. On most platforms an administrator can authorise us in minutes — no marketplace listing, no professional-services engagement, nobody from your vendor on the call.

Webhooks

Your system fires when a job is created, assigned or dispatched, and the work appears here. We answer in under a second and build the job behind it — most platforms allow a five-second budget, and doing the real work inside it is how these integrations fail.

Batch load

Tonight’s schedule, in one file, on a timer. The least glamorous integration there is and the one that works on the first afternoon.

SPSQLSync and direct SQL

For an on-premise system with a database you own, we read it on a schedule and keep the two in step. This is how the ESC shops run today.

The homegrown system somebody wrote in 2009 is the best case, not the worst. Every vendor tells you it is the hard part. If it is SQL Server or Postgres it is the easy part: we read exactly the tables a job needs and write the results back. No API roadmap to wait on and no vendor to ask permission from, because it is your schema and you already own it.

The REST API

Every capability in the platform is a documented REST route — and the same capability is an MCP tool, so an agent can create work the same way your integration does.

The open platform →

The external key is the join Every job we take in keeps your system’s id, for the life of the job, in both directions. That is what makes a second webhook update a job instead of duplicating it, and it is what lets the proof go back out to the right record at the end.

A dropped event is a late job, never a lost one Most platforms call webhook delivery best-effort — they retry for a while, then stop. So we never trust the webhook on its own. A reconciliation sweep reads back on a schedule and picks up anything that never arrived, and a redelivery is de-duplicated on your platform’s own event id rather than on a heuristic we invented. Where your platform keeps a delivery log, we read it — so a job that did not show up can be accounted for instead of argued about.

Then our rules fire

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.

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.
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.
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.
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.
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.

How rules and events work →

And the proof goes back out

A record nobody else can read is not proof of anything. What the field captured goes back to the system that bills it.

Back to your system of record — the times, the parts, the completion, the photos, against the same job id it came in with.
As documents — the story of the visit, assembled as the work happened rather than reconstructed on Friday, ready to hand to a general contractor or attach to an invoice.
To QuickBooks for the financial side. In build
Or straight out of the API, because every capability is a documented route and your data is yours. Read that promise in detail →

Files live on your storage if you want them to — your S3 bucket, your Azure, your Google Drive, your own server. A customer whose photographs sit in their own account cannot be held hostage, and we would rather compete on being worth keeping.

What switching your whole system really costs

Plenty of shops have looked at replacing their platform because one part of it was bad — usually the mobile app, sometimes the paperwork. That is a very big answer to a fairly specific question, and the bill is not the license fee.

The history you lose

Every service call, every part, every note going back years. Most migrations carry over a fraction of it, and the rest becomes a read-only archive nobody opens.

The months of disruption

Rebuilding price books, agreements, tax codes and workflows — while still answering the phone and running the trucks.

The office relearning everything

The people who know how to make your current system sing become beginners again. That cost lands on your most experienced staff.

The money, before the subscription

Conversion, data work, configuration, training, the consultants who do it and the overtime for the staff who help them. That is spent before the new system has saved you a dollar — and it is spent whether or not you end up liking it.

And you might still be unhappy

A new platform is a new set of compromises. The thing you were actually trying to fix — how consistently the work gets run — you can fix on its own, this month.

Extend the life of the system that already works. Replace only the part that doesn’t.

What a pilot looks like

One crew, one workflow, one month. Small enough that it cannot hurt you and real enough that you will know.

When	What happens
Days 1–2	We connect to your system — a webhook, a nightly file, or a read of a database you own — and today’s work shows up on a board. Nothing in your system changes.
Days 2–3	We write one workflow with you. The one your best tech already does in his head, and your newest one does not. That is the SOP.
Day 4	One crew installs the app. It is a web app — no app store, no MDM, no waiting on anybody’s approval queue.
Week 2 onward	They run it. You read what came back: the photos, the readings, the times, and how often the steps actually got done. Then you write the second workflow, and you already know how.

That is the whole commitment. If it does not earn its place in a month, you stop — and your system of record never knew anything happened.

Talk to us about a pilot Pricing →