Field service · Dispatch
MixedField serviceField service dispatch: spreadsheets, software, or agents beside it
Appliance repair and facilities teams lose most time before and after the visit: reading requests, picking a technician, and chasing parts. This guide compares three ways to run dispatch and where AI agents fit.
Valnora & Elric team6 min read
Compared in this guide
- AWho reads each request?
- BHow is a technician chosen?
- CWhat happens to job sheets?
- DWho chases parts?
- EWhat does the customer hear?
- FCost and effort to start
- GFits best when
An appliance repair company with twenty technicians takes requests on WhatsApp, from a web form, by email and from brand warranty desks. One coordinator reads them, works out the appliance and the area, rings round for a free technician and writes the job into a spreadsheet or a field-service app. After the visit, paper job sheets pile up, and nobody notices that a drain pump ordered nine days ago has not arrived until the customer calls, angry.
The visit itself is rarely the problem. The time goes before and after it. This guide compares three ways to run that work, and explains where AI agents in Agent Serve fit.
The three options
Manual. WhatsApp, a shared sheet and a whiteboard. It works for a few technicians in one area and breaks as soon as volume grows or the coordinator is off.
Field-service software alone. Scheduling, technician apps, digital job forms and customer notifications. It is the right system of record for jobs once you have more than a handful of technicians. It still expects a person to read each WhatsApp message and type it in, and parts chasing stays manual.
Agents beside the software. Keep your field-service software, or your sheet if you have none, and add agents for the reading, matching and chasing. This is what the rest of the post describes.
Three ways to run dispatch
| Question | Manual | Field-service software alone | Agents beside the software |
|---|---|---|---|
| Who reads each request? | A coordinator, from WhatsApp, calls and email, one at a time | A coordinator types it into the software, or the customer fills a fixed form | An agent reads free text and photos, fills the job fields and flags what is missing |
| How is a technician chosen? | From memory and a whiteboard | Scheduling by area and availability, with the dispatcher choosing | A suggestion from the technicians table with the reason; the dispatcher confirms |
| What happens to job sheets? | Paper in a folder, typed up at month end if at all | Digital forms, if technicians fill them in on the app | Paper or app; the sheet is read and summarised into the job and parts tables |
| Who chases parts? | Whoever remembers | Status fields exist; chasing is still manual | A Relay drafts supplier chasers and customer updates for approval |
| What does the customer hear? | Whatever the coordinator has time to send | Notifications built into the software | Your existing notifications, plus WhatsApp updates on parts delays |
| Cost and effort to start | Lowest, until volume grows | Licences and a rollout for every technician | Keeps the software you have; workflows built on top, model usage metered |
| Fits best when | Under a handful of technicians, one area | Many technicians, routes and SLAs to manage | Requests arrive as messages and parts delays drive repeat visits |
What the agents do
Agents beside field-service software
Workflow · Triage and match
- 01Service requestsWhatsApp webhook trigger, web form triggers and the service inbox in Gmail or Outlook.
- 02TriageReads appliance, brand, fault, warranty status, pincode and urgency from the request.
- 03Technicians tableSkills, brands, pincodes covered, today’s booked jobs and leave.
- 04Dispatcher confirmsSees the suggested technician and reason, then confirms or swaps.
- 05Job in your softwareCreated through the API block with your field-service software’s API key.
After the visit
- 06Job sheet photoTechnician sends a photo of the signed job sheet on WhatsApp; it is saved to Files.
- 07SummariseA parsing block reads the sheet; an agent writes fault, work done and parts needed.
- 08Parts tableOne row per part on order: job, supplier, ordered date, promised date.
Relay · Parts follow-up
- 09Parts RelayWatches the parts table for parts past their promised date.
- 10Approved messagesSupplier emails and customer updates wait for the service manager.
Triage. A workflow starts from the WhatsApp webhook trigger, a form trigger or the service inbox. An Agent block reads the message, and any photo of the model plate or error code, and fills the job fields: appliance, brand, fault, warranty status, pincode and urgency. If something is missing, such as the invoice for a warranty claim, it asks the customer on the same channel.
Matching. A technicians table holds each person's skills, brands, pincodes and today's booked jobs. The workflow filters by skill and area, prefers the technician with free slots and the fewest jobs, and shows the dispatcher the suggestion with the reason. A Human in the loop step lets the dispatcher confirm or swap. On confirmation, the workflow creates the job in your field-service software through the API block, using its API key stored as a workspace secret, and sends the customer the slot.
What the solution produces
Triage and match suggestion (illustrative)
Record- Request
- WhatsApp · "Front-load washer not draining, shows E21, 2 years old"
- Triage
- Washing machine · drain fault · likely in warranty · 560034 · normal
- Missing
- Invoice photo, to confirm warranty. Asked the customer.
- Suggested technician
- Ravi K. · washers, this brand · covers 560034 · 3 of 6 slots booked today
- Slot
- Today 15:00–17:00
Job sheet summary (illustrative)
Checklist- Job J-40218 · visited 15:40 · customer signature present
- Fault found: drain pump impeller jammed, pump motor weak
- Work done: cleared filter and impeller; machine drains slowly
- Part needed: drain pump assembly, ordered from the brand service depot
- Next: revisit when the part arrives; customer told 3–5 working days
Job sheets. After the visit, the technician sends a photo of the signed sheet on WhatsApp, or the app's PDF arrives by email. It is saved to Files, a document parsing block reads it, and an agent writes a short summary into the job: fault found, work done, parts needed and next step. Any part needed becomes a row in a parts table with the supplier and a promised date.
Parts follow-up. A Relay, an AI coworker with its own instructions and access, watches the parts table. When a part passes its promised date, it drafts an email to the supplier and a WhatsApp update to the customer. Emails always wait for approval, and the customer update runs through an allowlisted workflow that waits for the service manager under Assist autonomy.
A dashboard over the jobs and parts tables shows open jobs by area, jobs waiting for parts by age, and repeat visits. A monitor alerts the service manager when parts waiting more than a week pass the number you set.
How to decide
- Under five technicians, one area, few parts orders. Stay manual, but move the sheet into a table so you can add agents later.
- Many technicians and routes, requests mostly arrive in the app or by phone. Field-service software alone may be enough. Add agents later for parts follow-up if repeat visits are a problem.
- Requests arrive as WhatsApp messages and photos, and parts delays drive repeat visits. Agents beside the software pay off most, because they take on the reading and chasing the software leaves to people.
Whichever you choose, measure first: how long a request waits before it has a technician, and how many jobs need a second visit for parts. Any targets you set from this guide are illustrative until you have your own baseline.
Controls
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
More on how Agent Serve handles access, data and audit on the security page.
Every triage, match and summary is in the run logs, so a disputed visit can be traced from the original message to the technician who was sent. Workflows run from a deployed version, so changes to matching rules are reviewed before they reach live jobs.
Questions teams ask
Does Agent Serve integrate with our field-service software?
There is no built-in integration for field-service software. If yours has an API, the API block can create and update jobs with the key stored as a workspace secret, or you can connect it under Settings → Tool connections if the vendor offers an MCP server, a standard way for AI agents to call a tool.
Can the agent assign jobs without the dispatcher?
You can let the workflow assign routine jobs on its own once you trust it. Most teams start with every suggestion confirmed by a person, and keep it that way for urgent or high-value jobs.
What you need
- A technicians table: skills, brands, pincodes covered, working days and a daily job limit
- Your field-service software’s API documentation and an API key stored as a workspace secret, if you use one
- A WhatsApp Business number and the service inbox connected to Agent Serve
- A photo of a typical job sheet, to test the parsing step
- A parts table, or the sheet you track parts in today
- A dispatcher and a service manager named as approvers