How Do You Build a Field Service Dispatch System? 12 Technicians Dispatched via a LINE Group and 3 Wasted Trips a Day: A Complete Plan From Dispatch Rules to Offline Work Orders and Signed Sign-Off

Short answer: A field service dispatch system rests on three things: dispatch rules, offline work orders and on-site sign-off. For a team of 10–30 technicians, a custom build costs roughly NT$280k–600k and goes live in 10–14 weeks. With fewer than 5 technicians and under 10 jobs a day, a SaaS tool or a shared form is enough.

The scene: 12 technicians, one LINE group

An air-conditioning maintenance company has 12 technicians and about 45 work orders a day, all dispatched by a coordinator pasting addresses into a LINE group. Two technicians end up driving the same route separately, parts get left behind and someone drives back to the office, and the team wastes an average of 3 trips a day. At month end, two days go into matching photos and signed forms to invoices. The problem is that dispatch, field work and billing data are not connected.

When it fits and when it doesn't

A dispatch system suits teams with many jobs, scattered technicians and a need to prove work was done; it does not suit low volume or processes that change daily.

Alternatives matrix

Compare three alternatives first; custom only pays off when rules are complex or existing systems must connect.

Process breakdown

A standard project runs five phases over about 10–14 weeks, each with an acceptance deliverable.

• Weeks 1–2 | Rules audit: job types, skill tiers, regions and SLAs, delivered as a dispatch rule sheet in Notion.
• Weeks 3–4 | Design: wireframes for the technician app and dispatch console, delivered as a clickable Figma prototype.
• Weeks 5–10 | Development: a Laravel back end for dispatch and scheduling, a Flutter app for offline work orders, photos and signatures; push via Firebase Cloud Messaging, maps and routes via Google Maps Platform.
• Weeks 11–12 | Field pilot: three technicians use it for two weeks while forms and offline sync are fixed.
• Weeks 13–14 | Full launch: training, legacy data import, App Store and Google Play release.

Full cost breakdown

Beyond the build, reserve about 15–20% of the development fee each year for operations and third-party costs.

• Development: NT$280k (one job type) to NT$600k (multi-skill dispatch plus ERP integration).
• Maps and routing APIs: Google Maps Platform includes a free monthly allowance per SKU, then bills per request; 45 jobs a day usually stays within it.
• Store accounts: Apple Developer US$99 a year, Google Play US$25 one-time.
• Hosting and photo storage: about NT$1,500–4,000 a month; set retention limits when photo volume is high.
• Hidden costs: phone replacements, technician training hours, compatibility updates after major OS releases.

Reality vs expectation

The biggest gap is the expectation that the system will dispatch everything on its own.

• Clients expect fully automatic dispatch; in reality a coordinator still confirms jobs for the first three months while rules are tuned.
• Clients expect technicians to adopt the app willingly; in reality unless close-out is tied to billing, the app is quickly ignored.
• Clients expect sync to just work; in reality basements and plant rooms drop signal, so offline storage and conflict handling need explicit design.

Common pitfalls and how to avoid them

Most failures come from undefined processes, not technology.

• Rules live in the coordinator's head → write dispatch rules as a table and get sign-off before development.
• Too many form fields → no more than 8 required fields per work order; replace the rest with photos.
• No offline mode → store work orders and photos on the phone and auto-upload once back in signal.
• Photos kept forever → set an 18-month retention period so cloud costs don't double every year.
• Launching to everyone at once → pilot with 3 technicians for two weeks first.

Success metrics and a 90-day roadmap

Within 90 days of launch, wasted trips and billing time should both fall.

• Day 30: 90% of jobs closed in the app; wasted trips down from 3 a day to under 1.
• Day 60: dispatch suggestions by region and skill; coordinator hours down 30%.
• Day 90: close-out data flows straight to billing; month-end reconciliation shrinks from 2 days to half a day.

Decision checklist

If six or more apply, a custom dispatch system is worth evaluating.

• ☐ More than 8 technicians
• ☐ More than 20 work orders a day
• ☐ Wrong or duplicate trips happen weekly
• ☐ Close-out requires photos or customer signatures
• ☐ Some job sites have unreliable signal
• ☐ Technicians have skill or license tiers
• ☐ Integration with ERP or invoicing is needed
• ☐ Month-end reconciliation takes more than a day
• ☐ Someone can own and maintain dispatch rules
• ☐ You're willing to pilot with 3 people for two weeks

Frequently Asked Questions

How much does a field service dispatch system cost?

For 10–30 technicians, roughly NT$280k–600k, plus about 15–20% of that per year for maintenance and third-party fees.

What if technicians have no signal in basements?

The app must support offline work orders: photos and signatures stay on the phone, sync automatically when signal returns, and edit conflicts are resolved.

Why not just use an overseas field service SaaS?

With few technicians and standard processes, SaaS is cheaper; if you need Chinese forms, e-invoices or ERP integration, custom is usually simpler.

Next step

ScriptWalker (a Taiwan-based Laravel/Flutter custom development studio) offers a Field Service Dispatch App Build starting at NT$280,000, including rules audit, Figma prototype, offline work-order app, dispatch console and a 3-person pilot. Bring last week's work orders, and in 30 minutes we'll tell you whether to build custom, buy SaaS, or stay on forms for now.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p