Field service
Dispatching field technicians from a shared board
A dispatcher matches jobs to people who are already on the road, with promised arrival windows, required skills and a day that rarely goes to plan. The board has to make assignment fast and reassignment safe, while leaving routing and travel estimates to the systems that know geography.
A queue on one side, a moving day on the other
Work arrives continuously: a boiler repair booked yesterday, a warranty visit, an emergency call at 10:40. Each job has a customer, an address, an arrival window promised to that customer and a set of skills or certifications it needs. Until it is assigned, it waits in a queue the dispatcher works through.
Technicians are not interchangeable. One is certified for gas, another carries the parts for a specific model, a heavy installation needs a crew of two, and everyone has a home territory. Meanwhile jobs run long, vans break down and people call in sick, so the afternoon is rebuilt several times a day.
A timeline is the right tool for “who is doing what, and when”. It is the wrong tool for “which order of visits minimizes driving”, and a dispatch board should be honest about the difference.
The dispatcher’s calls
- 01
Who takes the job
Skills, certifications, territory and parts on the van narrow the list. The dispatcher picks among the remaining technicians by workload and where they will be.
- 02
Whether the promised window still holds
An 08:00 to 12:00 arrival window is a commitment. Placing a job at 11:30 after a long installation may be free on screen and late in practice.
- 03
How much travel to allow
Two jobs on opposite sides of a city are not back-to-back in reality. Dispatchers leave gaps or insert travel blocks based on what they know of the route.
- 04
What to do when a job overruns
When an installation takes two extra hours, the rest of that technician’s day has to shift, be handed to someone else or be rebooked with the customer.
Modeling the dispatch board
Keep unassigned work outside the grid and assigned work inside it, and let the drop between the two be the moment your backend records an assignment.
- Resources
- Rows are technicians, optionally grouped by crew or region in a resource tree, with columns for territory, skills or van. The application narrows the rows to candidates with rows.filter and onRowFilter.
- Events
- An assigned job is an event on a technician row with the customer reference, arrival window and status as custom fields. Travel can appear as a separate locked event, with moveDisabled and resizeDisabled, that your code creates and maintains.
- Time scale
- Use hourly cells for today’s dispatch and day cells for the week ahead, as two zoom levels. Disable the cells outside each technician’s shift so jobs cannot be dropped into time off.
- Rules
- The unassigned list uses makeDraggable, so dropping an item on a technician creates an event and fires onEventMoved with args.external set. In onEventMoving, refuse a drop on a technician without the required skill or outside the arrival window, with a message saying why. Enable event selection and allowMultiMove so several jobs can shift together.
Board versus back office
- Dragging jobs from an external list onto a technician and a time
- Row filtering by skill, region or crew
- Multi-selection and moving several jobs together
- Refusal with a message when a drop breaks your rule
- Job cards and detail panels rendered as React components
- Route optimization, travel-time estimates and maps: the library does not plan routes
- Job intake, customer communication and the arrival windows you promise
- The technicians’ mobile app and status updates from the field
- Skills, certifications and territories as data, and the matching rules
- Sync between dispatchers and conflict resolution on the server
- Time-zone conversion for teams spread across regions
Working examples
Mistakes dispatch boards repeat
Reading the timeline as a map
Two adjacent bars say nothing about distance. Without travel blocks or a check from your routing service, a day can be free on screen and impossible on the road.
Removing the job from the queue too early
Take the item off the unassigned list only after the backend confirms the assignment. A second drop with an id that is already loaded is skipped with a console warning, which can hide a real duplication problem.
Mixing time zones on one board
Times are civil and carry no zone. A team that spans zones needs one display zone chosen by the application, with conversion before data reaches the timeline.
Validating only on the board
Two dispatchers can give the same technician the same slot at the same moment. The server decides, and the board reloads the result.
Questions
Does SuperScheduler optimize technician routes?
No. It has no routing, geocoding or travel-time engine. It shows the plan and lets dispatchers change it; your application or a routing service suggests visit order and travel estimates, which you can draw as events.
How do I drag unassigned jobs from a list onto the schedule?
Call SuperScheduler.Scheduler.makeDraggable on each list element with an id, a text and a duration. Dropping it on a row creates an event and fires onEventMoved with args.external set to true, which is where you send the assignment to your backend.
Can I show only the technicians who have a given skill?
Yes. Store skills on each resource, call rows.filter with the selected skill and decide visibility in onRowFilter. Filtering changes which rows are shown, not who may be assigned, so validate assignments on the server as well.
Can a dispatcher move several jobs at once?
Yes. With event selection and allowMultiMove enabled, selected jobs move together when one of them is dragged, and the change arrives through the usual handlers for your backend to accept or reject.
Try the Fieldwork demo
Fieldwork, a fictional service company, assigns a pending job from a list to a crew and checks availability on the board. It does not pretend to optimize routes.
Working examples