The dispatcher is looking at a gap after lunch. It appears large enough for another service call, but the technician does not have the required part, the previous job is across town and the customer cannot provide access before the afternoon window ends. A calendar can display the gap correctly while recommending the wrong assignment.
A useful field service management system distinguishes empty time from a feasible visit. Start with the decisions dispatch already makes, including the ones held in memory. The board should make those decisions easier to inspect, not replace them with an unexplained coloured block.
Availability is only the first filter
Represent a job with the information needed to assign it: service type, required capability, site, expected duration, access window and any required equipment. Keep uncertainty visible. A diagnostic visit with an unknown repair duration should not look identical to a routine inspection with a known checklist.
Represent a technician's availability separately from their eligibility for the work. Time off, working hours and existing assignments describe availability. Skills, approved work categories and any business required credentials describe eligibility. Expired or missing information should have a defined consequence, such as requiring dispatch review, rather than silently being treated as valid.
Do not attach every rule to a job title. A technician might be able to complete one type of installation but need another qualified person for a particular task. Model the operational distinction that dispatch uses, and have the team lead review it before the system begins enforcing it.
Reserve resources together
Some visits require two people, a specific tool or access to a shared vehicle. Assigning the lead technician alone can create a schedule that cannot be executed. The reservation needs to cover all required resources for the relevant period, including preparation and travel where applicable.
Make assignment atomic at the application boundary. Two dispatchers working simultaneously must not both reserve the same exclusive resource after seeing it available. The database or scheduling service needs a concurrency control appropriate to the resource model. Show the losing request a clear availability update rather than allowing both screens to display success.
Shared capacity needs a different rule from exclusivity. A workshop resource that supports several concurrent tasks cannot be represented correctly by a simple no overlap constraint. Write the capacity rule explicitly and test the last available place with concurrent requests.
Travel belongs between jobs
Travel time depends on the sequence. Storing one fixed allowance on every job may be useful for an initial estimate, but it cannot describe every move between sites. Calculate or enter the relevant travel estimate between assignments and show where it makes an arrival window infeasible.
Treat the estimate as an estimate. Mapping data does not know that a loading entrance is closed or that the technician needs to collect a part first. Let dispatch record an operational override with a reason. Keep the original estimate visible so later review can distinguish an informed adjustment from an accidental drag on the board.
When a job runs long, show the downstream effect before sending new promises to customers. The next appointment may still be feasible within its window, while the one after it needs reassignment. Moving every subsequent job by the same amount can create unnecessary changes.
Reassignment is a workflow, not a drag event
Dragging a job to another column should create a proposed reassignment. Check eligibility, resource conflicts and the current job state. A technician already travelling needs a different transition from a visit still unassigned for next week.
Decide who acknowledges the change and what dispatch sees until that acknowledgement arrives. If the mobile device is offline, a successful server update does not mean the technician has seen it. Display the last acknowledged assignment alongside the new proposal so the office can choose an appropriate contact method.
Preserve the history: previous technician, replacement, reason and time. That record is useful when a customer asks who is arriving or when equipment notes were prepared for the original assignee. It should not be possible for a later edit to erase the fact that responsibility changed.
Urgent work must expose what it displaces
An urgent call can require overriding the normal sequence. The software should support that decision without pretending there is no tradeoff. Present the jobs affected, their customer windows and the resources that would need to move.
Keep priority separate from severity labels supplied by an incoming form. A customer selecting urgent should flag the request for review, not automatically authorise the system to cancel existing commitments. The business needs a clear triage rule and a responsible operator.
After the change, create a communication queue for affected appointments. Record which customers were notified and which notifications failed. A board that looks tidy after reshuffling can still leave customers waiting against the old arrangement if communication is outside the workflow.
Test the board with an ordinary messy day
Use a scenario containing an overrun, a missing part, a technician becoming unavailable and a customer changing access instructions. Ask a dispatcher to complete the day using the proposed interface. Observe what they still write on paper or send in a separate message.
Test two dispatchers editing the same visit. Test a technician accepting an assignment after it has been withdrawn. Test an offline device reconnecting with an old job status. Each outcome should preserve the current assignment and explain any rejected change without losing useful field notes.
The acceptance question is not whether the board displays every job. It is whether dispatch can identify the next decision, understand its consequences and communicate the result. That is the difference between a scheduling picture and a working dispatch system.