The Ops System Behind a Text Message

A restoration operator we work with had a problem that every field-services business has and almost none of them can fix: nobody knew where the jobs were.

Not physically. They knew the addresses. They didn't know the status — which jobs were waiting on an estimate, which were stuck on an insurance supplement, which had been approved and were bleeding cash while nobody chased the payment. That information existed, but it lived in the worst possible place: in the crew's heads and in a dozen group text threads. Ask the owner "which jobs are stuck right now, and how much money is sitting in them," and the honest answer was a shrug and an afternoon of phone calls.

This isn't a small problem. In restoration, the money loop is estimate → supplement → approval → cash, and it's long — industry days-sales-outstanding runs anywhere from 45 to 120 days. Every job that silently stalls somewhere in that loop is real money frozen in place. When you can't see the stalls, you can't unstick them, and the working capital of the whole business quietly gets tied up in jobs nobody's actively pushing.

Why the obvious fix had already failed

The obvious fix is a field-management app. Give every tech a phone app, have them update job status as they go, and now you've got a live dashboard. Every vendor in the space sells exactly this.

It had been tried. It had failed, the way it always fails. The techs would not open the app.

And here's the thing — they're not wrong to resist. A restoration tech is standing in a flooded basement in a Tyvek suit with wet gloves. His job is the water, the equipment, the homeowner who's having the worst day of their year. Stopping to open an app, wait for it to load, tap through four screens, and fill in required fields is a genuine imposition in that moment, and it competes with actual work. So it doesn't happen. The app sits unused, the dashboard stays empty, and management concludes the crew is undisciplined. The crew isn't undisciplined. The tool asked them to change how they work, and in the field, the work wins every time.

I've watched companies fight this war for years — more training, more nagging, more mandatory-app policies — and the field always wins. You cannot out-discipline the reality that a person doing physical work will not stop to feed software. So we stopped trying.

Meet the crew where they already are

Here's what these techs will do, all day, without being asked: text.

They're already in group threads. They already fire off "job at 402 done, homeowner wants a callback about the kitchen" without thinking about it. Texting isn't a new behavior we had to install — it's the behavior that was already there, the one the actual status updates were already flowing through, just into a format nobody could use.

So we put the intake behind the text thread. No app. The crew texts what happened, in plain English, the way they already do. Behind that thread, a model reads each message and pulls out the structured events — this job moved to this stage, this amount was quoted, this one's waiting on the adjuster, this one needs a callback. Those events land in a real system. And on top of that system sits the thing the owner actually wanted all along: a dashboard that ranks stuck jobs by dollars at risk.

From the crew's side, nothing changed. They text like they always did. From the owner's side, everything changed. He opens one screen in the morning and sees every job that hasn't moved, worst-money-first, and spends his day unsticking the expensive ones instead of discovering them 60 days late.

The principle: the best data model loses to the one that gets fed

There's a lesson in this that goes way past restoration, and I've come to treat it as a rule.

The best data model in the world loses to the one that actually gets fed.

You can design a beautiful, comprehensive, perfectly-normalized system for capturing field data. Every status, every subcategory, every field a manager could ever want to report on. And if feeding it requires a person doing physical work to stop and change their behavior, it will sit empty, and your beautiful model will be worth exactly nothing. Meanwhile a scrappy system that captures 80% of the value through a channel people already use — a text thread — will be full, and a full system that's slightly imperfect beats an immaculate system that's empty every single day of the week.

This flips how you should design ops tooling for anyone who works with their hands. Don't start from "what data do we want to capture" and then push that burden onto the field. Start from "how does this crew already communicate" and build the capture behind that. The channel is fixed — it's whatever they'll actually use. The intelligence goes on your side of the wire, turning their natural, messy, plain-language messages into structure. You adapt to the crew. You don't make the crew adapt to you.

The app-first approach gets this exactly backwards, which is why it keeps failing. It optimizes for the clean data model and treats the human behavior as the thing that needs to change. But the human behavior in the field is the one thing you can't change, and the data model is the one thing you can. Build accordingly.

What it bought them

The restoration operator didn't get a fancier app the crew would ignore. They got visibility, out of a behavior that was already happening. Stuck jobs surface the same week they stall instead of two months later. The owner works the loop by dollars instead of by whoever happened to complain loudest. And the crew never had to learn, adopt, or resent a single thing — because from where they stand, they're just texting.

That's the whole trick, and it's not really a technology trick. It's a decision about where to put the effort: on your side of the wire, not on theirs.

What used to make this impossible

Here's what's actually new, because meeting the crew where they are isn't a new idea — every good operator has wished for it. The reason it never worked before is that plain-language text was useless as data. A message like "finished demo at Riverside, found mold behind the kitchen wall, need a supplement" was just a string of words. To turn it into a job status update, a human had to read it and re-key it into a system, which put you right back where you started: someone at a desk, doing data entry, falling behind.

What changed is that a model can now read that messy sentence and reliably pull the structure out of it — the job, the stage, the dollar event, the next action — without a human in the middle. That's the piece that was missing. The channel the crew would actually use (text) and the structure the business actually needs (clean job records) were always incompatible, and a person had to bridge them by hand. Now the machine bridges them. That's the whole reason this approach is suddenly practical for a small operator instead of a fantasy — the translation layer got cheap enough to sit quietly behind a text thread.

If your field team's status lives in heads and group chats and you can't see where the money's stuck, the fix probably isn't another app to ignore. Here's how we work.