Leadership wants the map on the wall. Live jobs, live techs, live ETA. Every field on the dispatch board updating in real time, exceptions surfaced automatically, coverage gaps flagged before the supervisor has to call someone. That is a compelling picture. It is also a bad first AI project.
It is a good later problem.
The companies that start AI deployment on the dispatch board — facilities services companies, energy infrastructure operators, security and surveillance firms, trade contractors — share a pattern. The pilot runs for 60 days. Something goes wrong in a way that the whole operations floor sees. The supervisor loses confidence. The dispatcher goes back to the whiteboard. The operations manager tells the CEO that AI does not work in their environment. Six months later the licenses are unused and the conversation is over.
The companies that start with accounts payable share a different pattern. The pilot runs for 30 days. The AP coordinator gets time back. The controller notices the exception rate dropped. The project managers stop getting chased for PO approvals on their phones during service calls. The operations manager sees the result and asks what else the model can do. Six months later the workflow is load-bearing and three more have been added.
The choice of where to start is the most consequential operational decision in any field service AI deployment. This note explains why AP is almost always the right answer, what AP actually looks like in trades and technical field service, and how to sequence from a working AP workflow into the rest of the operation.
Why dispatch is the wrong first project
Dispatch is the most visible operation in any field service company. It is also the most political. Every supervisor has an opinion about how the board should be managed. Every technician has a preference for how jobs are assigned. The dispatcher has institutional knowledge — relationships, geography, skill matching, customer history — that is almost impossible to fully encode in a model's context window.
When AI dispatch goes wrong, it goes wrong in public. A tech gets sent to the wrong job. A high-priority call gets delayed because the model deprioritized it. A customer calls angry because nobody showed up during the promised window. The whole operations floor sees it happen. The whole operations floor forms an opinion about AI based on it.
That opinion is very hard to walk back. A failed dispatch AI is not just a failed workflow — it is evidence for every skeptic in the building that the technology does not understand the real complexity of their operation. And in a field service company where trust in systems and tools is built slowly over years, that evidence sticks.
None of this means AI cannot help with dispatch. It can, and for high-volume operations with a drowning dispatcher, it can help significantly. But it should not be the first thing you prove. It should be something you prove after you have already demonstrated, in a lower-stakes environment, that the model produces reliable output and the team has learned to trust it.
What AP actually looks like in trades and technical field service
The accounts payable workflow in a field service company is almost universally described the same way by the people who run it: a pile that never gets smaller.
A vendor invoice arrives as a PDF in a shared inbox. The AP coordinator needs to find the purchase order. The PO might be in the work order system, in a spreadsheet, in an email chain, or in a folder on someone's desktop. Once they find the PO, they need to match the invoice amount, the vendor name, and the line items to the PO. If there is a discrepancy — a quantity mismatch, an unapproved line item, an invoice for work that was not completed — they need to track down the project manager or supervisor who authorized the work.
That project manager is in the field. They are in a truck between service calls. They are on a roof or in a mechanical room or driving between accounts. The AP coordinator sends an email. The PM sees it six hours later. The PM replies from their phone with incomplete information. The AP coordinator goes back with a follow-up question. Three days pass. The vendor calls wondering where the payment is.
This loop runs on every invoice, in every field service company, in every vertical. Facilities services. Energy infrastructure. Gate and entry. Low voltage. Security. HVAC. Commercial cleaning. The specifics of the invoice change. The loop does not.
The cost of this loop is not just the AP coordinator's time, though that cost is real and measurable. It is the delay in closing jobs, the vendor relationships that fray under slow payment cycles, the month-end scramble when accounting discovers invoices that were approved but never posted, and the job cost variances that appear in the P&L because a subcontractor invoice got coded to the wrong job three months ago and nobody noticed until the quarter closed.
For a PE-backed field service company with a sponsor watching the EBITDA line, that last cost is the most significant. Margin that disappears into AP processing delay and coding errors is margin that shows up as a variance with no clean explanation.
What the model should do in AP
The model's job in AP is not to replace the AP coordinator. It is to eliminate the manual chase.
The AP coordinator should not be hunting for PO numbers across three systems. The model should read the invoice, extract the vendor name, invoice number, amount, and line items, and search the work order system and PO database for the matching record. If it finds a clear match with no discrepancies, it drafts an approval routing — PO number confirmed, job code assigned, amount matches, ready for PM review. If it finds a discrepancy — a quantity off by one unit, an invoice amount that exceeds the PO by $200 — it flags the exception with the specific discrepancy identified and routes it for review with the relevant context already assembled.
That draft lands in the channel the PM already opens. Not a new app. Not a new system. The Teams channel the PM is already in, the email thread they are already managing, the Slack workspace the team already uses. The PM sees a structured draft with the relevant context — invoice amount, PO amount, discrepancy flagged, job code suggested — and approves, corrects, or rejects with one or two keystrokes. The controller posts through the system's own path.
The AP coordinator's job changes. Instead of hunting for POs and chasing PMs, they are reviewing the model's exception flags and handling the cases the model cannot resolve — vendor disputes, contract questions, multi-job allocations that require judgment. The work that required judgment stays with the person. The work that required only time is handled by the model.
That is a meaningful shift in a business where AP processing is running 20-30 hours a week of coordinator time on a team that could be doing higher-value work.
Sequencing from AP into the rest of the operation
A working AP workflow — one that has run for 30 days, produced reliable output, earned the controller's trust, and demonstrably reduced the invoice-to-approval cycle time — is not just a useful workflow. It is a proof of concept that changes the conversation in the building.
The operations manager who was skeptical about AI because of something they heard about a chatbot failure now has a reference point. The model does this specific thing, with this specific structure, and produces this specific output that the controller trusts. That is no longer theoretical. That is a working system.
From that reference point, the sequence into the rest of the operation follows a clear path. Billing packets are the natural next workflow — the model has already demonstrated it can read job cost data and match to purchase orders, and the same read-then-draft-then-approve structure applies directly to assembling billing packets for completed jobs. Timesheet exceptions follow — labor cost is the largest line item in most field service P&Ls, and exception-based visibility into overtime, missed punches, and coverage gaps is high-value and structurally similar to the AP exception flagging the model is already doing.
From billing packets and timesheet exceptions, the path to work order operations, field reference, and eventually dispatch support is a series of incremental expansions of a proven pattern — not a new AI project with new risks, but a known structure applied to an adjacent workflow.
That sequencing is the difference between a company that describes itself as using AI and a company that has built AI operations into the way the business actually runs.
The first month in practice
Sit with the AP coordinator. Not for a discovery call. Watch them process the pile for two days. Count the invoices. Measure the average time from receipt to approval. Note where the process breaks down — which vendors are always late, which PMs are always slow to respond, which job codes are always mismatched.
Write the skill file. What the model reads, what it drafts, who approves, what it never does. Review the skill file with the controller before connecting anything.
Connect read access to the invoice inbox and the PO database. Run the model in parallel with the existing manual process for 30 days. The coordinator processes the pile manually. The model produces its drafts alongside. Compare the outputs. Measure the error rate. Measure the exception catch rate.
If after 30 days the model's error rate is acceptable and the controller trusts the output, retire the parallel and run the skill as primary. Keep the human gate. Keep the approval log. Keep the audit trail.
Start the next workflow.
The map on the wall will come. Dispatch support, real-time coverage visibility, route optimization — those are real operational improvements that field service companies need and that AI can genuinely help with. They come faster, and they last longer, when they are built on a foundation of proven, trusted, human-gated workflows that the team already believes in.
Start where failure is quiet and the fix is visible. Start with accounts payable.
The first win is not only measured in hours returned. It is the moment the team can see where judgment belongs. Clear matches move quickly; ambiguous invoices arrive with the evidence needed to resolve them. That distinction makes the AP coordinator more effective and gives leadership a more honest picture of where the operation still depends on people, relationships, and context that no model can infer safely.
It also gives the company a repeatable standard for every later workflow. Before expanding, ask whether the input is narrow enough to read, whether the draft can be checked, whether one person owns the decision, and whether the result can be audited after the fact. If any answer is no, the next workflow is not ready.