Work Order Automation: From Intake to Paid

The pipeline nobody drew

A maintenance business rarely thinks of itself as running a pipeline. It thinks of itself as answering the phone. But every request takes the same trip, and it either finishes or it does not: capture, route, track, bill, collect.

Requests are rarely lost inside a stage. What fails is the seam. A technician finishes a job in the field — the end of tracking, the beginning of billing — and nothing carries the information across the gap, so a person has to remember. At low volume, memory is a fine system. Past a certain volume, memory is the system, and it starts quietly dropping jobs.

Naming the stages before you touch any software turns every later decision into the same three questions: which stage, which handoff, and what has to be true for a job to cross it.

Capture: getting the request into one place

Capture is not just receiving a complaint. It is converting a human sentence — “the AC in 214 is making a noise again” — into a record that can be worked: location, trade, description, who reported it, when, how urgent.

Four channels at once. Email to the office, a phone call, a text to a technician's personal cell, a ticket in a client's portal. No single surface sees all four, so nobody can say what is open right now.
The one that came in by phone and was never written down. Invisible by construction: you cannot count what was never recorded.
Duplicates. A resident reports the leak and the property manager reports the leak. Two records, and on a bad day two vendors and two bills.
No sort by urgency. An inbox sorts by arrival time, so a burst supply line and a squeaky cabinet door take the same place in the list.

Safe to automate: intake and normalization. Every channel lands in one queue, the text is read once and split into fields, and a first pass proposes a trade and an urgency. Two requests naming the same unit and trade inside a short window get flagged instead of silently becoming two jobs. Field photos enter the same way — a technician texting pictures from the site is capture, not paperwork, and the queue should treat it as such.

Keep human: genuine ambiguity, and the priority override. Software proposes “plumbing, urgent” well enough. A person who knows the building is better at “that unit has an elderly resident, move it to the top.”

Route: getting it to the right hands

Routing looks like picking a vendor. It is really two things: picking, and getting back a commitment you can rely on.

Dispatch by whoever answered the phone rather than by trade and area. The person holding the request picks whoever they used last — a reasonable heuristic and a terrible policy.
The vendor who never confirmed, and nobody noticed. The request sits in a state called “dispatched,” which feels like progress while nothing at all happens.
The emergency that went to a vendor who does not do after-hours. Discovered at eleven at night, by the person least able to fix it.

Safe to automate: the shortlist, the send, and the clock. A system holding trade, service area, after-hours coverage and paperwork status produces a ranked shortlist instantly, sends the request, and starts a timer: no confirmation inside the window, escalate and tell a human. The clock is the underrated piece. Most routing failures are not picking the wrong vendor — they are never finding out that the right one did not answer.

Whether a vendor's insurance certificate is current belongs here too, as a warning rather than a hard stop — a dispatch blocked at 6pm on a Friday by an expired document helps nobody. That has its own answer, in automating vendor paperwork.

Keep human: the choice itself when real money or a real relationship is on the line, and what counts as an emergency.

Track: knowing where it actually stands

Tracking has two jobs: keep an honest picture of every open job, and collect the evidence you will need later.

The “any update?” tax. Someone spends a slice of every day asking vendors for status and photos, asking again, and feeling rude about the third attempt.
Jobs finished in reality and open in the system. Once the ledger drifts from the world, every report built on it is wrong — and people who stop trusting it stop updating it, which makes it worse.
No proof of completion. Weeks later a client disputes the work, and the whole defense is the recollection of someone who may no longer work there.

The chase is not the work

Asking a vendor for a status update produces nothing on its own; the job does not move faster because you asked. Value appears only when the answer lands on the record where the next person can see it — which is the argument for automating the asking and never automating the reading.

Safe to automate: the asking. A scheduled nudge to the assigned vendor — status, and a photo when it is done — costs nothing and never forgets. Replies and photos attach themselves to the record, and jobs that go quiet past a threshold raise a flag instead of aging silently.

Keep human: looking at the photo and deciding whether it shows finished work. That is a five-second judgment a person makes well and software makes confidently and wrongly.

Bill: turning finished work into an invoice

Billing converts a completed job into a document somebody will pay. By this stage every fact you need already exists somewhere, which is what makes the failures here so galling.

Invoices written from memory, days later. Details soften, a line gets dropped, and the description does not match what the client was told on the phone.
A markup applied inconsistently. It depends who built the invoice and what kind of week they were having, so margin varies for reasons nobody can reconstruct at the end of the quarter.
The completed job that nobody ever billed at all. The most expensive failure in the whole pipeline: full cost out, no revenue in. Also the quietest — nothing in an inbox reminds you about an invoice that was never created.

One query, run once

Jobs marked complete more than thirty days ago with no invoice attached. Write it against whatever you keep records in, and run it a single time.

We will not tell you what the answer should be — it is your number, and only yours means anything. But if the result is not empty, you have just measured your current process without needing anybody's statistics.

Safe to automate: the draft, and the detection. Assembling the document is clerical work — scope, vendor cost, markup rule and photos are already on the record. The standing “completed, never billed” sweep is the cheapest thing in this article and the likeliest to find real money. Our back-office automation builds both as a matter of course.

Keep human: sending it. A dollar figure leaving the building addressed to a customer waits for a person, every time.

Collect: turning an invoice into money

An invoice is not revenue. Collection is the stage that puts a clock on the difference.

No clock at all. Nobody owns day thirty-one, so receivables age by neglect and the oldest get the least attention.
Polite reminders that never get sent. Everyone intends to send them. Nobody wants to be the person who asks a good client for money.
Vendor bills paid without being checked against the work order or the quote. Money goes out for work that cannot be tied to a job, or at a number nobody agreed to in advance.

Safe to automate: the aging clock, the drafting of the reminder, and the three-way check between work order, quote and vendor bill. When those three disagree, a person hears about it before a payment is scheduled rather than after.

Keep human: pressing send on a reminder to a client you value, and approving every payment that leaves the account.

What to automate first

Start where the work is high-volume, rule-shaped and low-risk. Not where it is high-risk and low-volume. In practice that means capture and tracking first, billing drafts second, anything that moves money last.

That order is not a claim that money matters least — it is where the value is largest. It is a claim about trust. The first automation you ship teaches everybody whether to believe the system, so ship the boring one, let it be right for a month, then move up the risk curve with an audience already on your side.

To rank your own candidates, score each on three questions:

How often does it happen? Something that occurs twice a year is a checklist, not an automation.
How mechanical is the decision? If the rule fits in one sentence and holds most of the time, it is a candidate. If the honest description starts with “it depends,” it needs a person — or a machine to propose and a person to approve.
What happens if it is wrong? A mis-tagged trade is corrected in five seconds. An invoice sent at the wrong number is a phone call. A vendor bill paid in error is money you have to go and get back.

Your best first automation scores high on the first two and low on the third. Here is how the five stages usually sort out.

Stage	Safe to automate now	Automate with a gate	Keep human
Capture	Multi-channel intake, field extraction, duplicate flagging, proposed trade and urgency	The acknowledgment that goes back to whoever reported it	Final priority when someone knows the building and the resident
Route	Shortlist by trade, area and coverage; sending the request; the confirmation clock and escalation	Vendor selection where cost or a relationship is at stake	What counts as an emergency, and after-hours judgment
Track	Scheduled status nudges, photo and reply capture, stale-job flags	Closing a job on the vendor's word alone	Deciding whether the photos show finished work
Bill	Invoice drafted from the record, markup applied by rule, the “completed, never billed” sweep	Sending the invoice to the client	Any pricing exception, and any credit
Collect	Aging clock, reminder drafts, three-way match on vendor bills	Reminder sends and payment approvals	The conversation with a client who is late for a reason

The human gate

Two categories wait for a person: anything that spends money, and anything that leaves the building addressed to a customer. Everything else can flow.

It is short on purpose. It does not ask you to anticipate every way a system can be wrong — only to notice which side of one line an action falls on, which anybody on the team can answer in a second.

An approval queue sounds like a limitation — a person still has to click. The difference is what the person is doing. Instead of doing the work and making the decision, they only make the decision, and it arrives assembled: the job, the photos, the vendor's number, the markup, the resulting invoice, all on one card. A day that used to be a pile of half-finished tasks becomes a list of decisions.

It earns its place a second way: it is the one place where the system's judgment is visible before it reaches anybody outside, so a wrong proposal gets caught and turned into a tightened rule. A pipeline with no gate is one whose mistakes are reported to you by the person you would least like to hear them from.

What “done” should mean in a system

A job is not closed because someone said so. It is closed because there is evidence attached to the record: photos of the finished work, a note in plain language describing what was actually done, and a sign-off from whoever accepted it. Three things present before the status is allowed to change.

That definition does more work than it looks like:

Tracking becomes self-terminating. The chase stops when the evidence arrives, not when somebody remembers to stop asking.
Billing becomes possible without memory. The invoice description writes itself from the note.
Disputes get short. The answer weeks later is a link, not an argument.
The ledger stays true, so anything you count from it — open jobs, cycle time, spend per building — means something.

Take this one if you take nothing else. It costs nothing to define, you can adopt it this week with no software at all, and it is the difference between a records system and a rumor.

What automation will not fix

Three problems look like software problems and are not.

Bad vendor relationships. A workflow that texts a vendor who does not answer produces a well-documented non-answer. Useful — you find out on day one instead of day nine — but the problem is still the vendor. Automation hands you evidence faster; deciding to replace someone remains a human act, and an uncomfortable one.

Unclear scopes of work. If nobody wrote down what “make the unit ready” includes, no system can bill it correctly or judge whether it is finished. Ambiguity in, ambiguity out — now faster, and in a nicer font.

A business where nobody has decided who owns a decision. Every approval queue asks the same question: who approves this? If the honest answer is “whoever is around,” the automation surfaces that rather than solving it. Worth something, but not a fix. The fix is a conversation between people, held before the build.

Map your own pipeline in twenty minutes

Take two recent jobs — one that went well, one that went badly. For each, write down in order every place the information moved: an inbox, a phone call, a whiteboard, a text thread, a spreadsheet, someone's head. You are drawing handoffs, not steps.

Then, for each handoff, answer three questions:

What crosses here? A request, a commitment, a status, a price, a document. Name it.
Who has to remember for it to cross? If the answer is a person rather than a rule, put a mark next to it.
How would you know if it did not cross? If the answer is “we would find out eventually,” put two marks next to it.

Count the marks. The handoffs carrying the most of them are your queue, in order. Run the top few through the three ranking questions above and take the two that come out on top. That is your first build; everything else waits.

Twenty minutes with a pen is enough; longer, if you are honest about the second job. If you would rather do it with somebody who has drawn a few of these, that is what a discovery call is: thirty minutes, we map your pipeline together, and you leave with the map and three named automations whether or not you ever hire us. Request a quote and tell us the worst handoff you have.

Work order automation, from intake to paid