A service dispatcher in Aarhus has twelve visits to allocate before the phones get busy. One customer needs two engineers, another requires a specific qualification, and a replacement component is still travelling from Copenhagen. A route optimiser produces a tidy map. By midmorning, the dispatcher has rebuilt half the plan manually.
Technician scheduling software needs a model of feasible work before it needs a model of efficient travel. For Danish service businesses, a useful development project begins with the constraints dispatchers currently remember: access windows, qualifications, equipment, parts, paired visits and commitments already made to customers.
Turn dispatch knowledge into explicit rules
Sit with the person who plans the day and record why candidate assignments are rejected. Some reasons are mandatory: a technician lacks an approved qualification, a customer site is closed, or a job requires a second person. Others are preferences, such as continuity with the previous engineer or avoiding an inconvenient but possible journey.
Keep those categories separate. A system should never trade away a mandatory rule merely because doing so improves a travel score. Business owners should also approve the priority between softer goals. Reducing kilometres, meeting appointments and distributing inconvenient shifts are different objectives; there is no universally correct weighting.
Google's OR-Tools constraint optimisation documentation explains the use of constraints to narrow a large set of possible assignments. Its employee-scheduling example illustrates coverage and preference modelling. These are engineering foundations. Your company's operating rules, planning screen and integrations remain application work.
Schedule the part and the person together
A job can be technically assigned while still being impossible to complete. Represent the equipment and parts needed at arrival, including where they currently are and whether a transfer is merely planned or confirmed. The software should distinguish a service visit that can proceed from one that depends on an unresolved delivery.
Give expected job duration a source. A fixed duration may be suitable for a well-understood task; an uncertain investigation needs a different planning assumption. Capture actual completion times so the team can improve estimates, while avoiding the assumption that the fastest historical visit is a fair target for every future engineer.
Travel time also needs context. Include the relevant vehicle, departure period and access restrictions in the chosen routing integration. A plan suitable for a normal road journey may fail where a site requires booking, an island crossing or restricted entry. Treat those as declared inputs instead of relying on a dispatcher to discover them after publication.
Preserve the part of the day people already trust
Optimisation can create operational churn. A new urgent job may cause the solver to move every appointment, even if the resulting plan is mathematically attractive. Customers and technicians experience those changes as broken promises. Include a freeze horizon or an explicit cost for changing published commitments.
Let the dispatcher pin particular assignments with a reason. A pinned visit should remain visible to the optimiser as a constraint rather than disappearing into a manual spreadsheet. Record who changed the plan and which assumptions were used. When someone challenges a decision later, the system should be able to show the plan that existed at that time.
The mobile app must know which plan revision the technician accepted. If the connection drops, a new dispatch should not appear as though it has already been acknowledged. Keep a clear queue of proposed changes and provide a safe way for staff to reconcile an old offline plan with the latest published schedule.
Explain an impossible day
A useful planner can say that no feasible solution exists under the current rules. It should then help a person understand the shortage: a missing skill, insufficient paired capacity, an unavailable part or conflicting time windows. Hiding an unassigned job off-screen is not an acceptable resolution.
Allow reviewers to explore specific alternatives. Moving a flexible appointment, adding an approved subcontractor or splitting a task may create a feasible plan. Show the consequence of each authorised change. Employment, safety and contractual requirements must come from the business's qualified owners; the software team should not invent them to make a schedule fit.
Keep the previous workable plan available when a planning service times out. The interface should state whether the result is feasible, whether an improvement was found and when it was generated. A stalled optimisation job must not block the dispatcher from operating the business.
Commission a shadow-planning pilot
Run the proposed system alongside the existing process before it starts publishing assignments. Feed it a representative sample of days and compare its suggestions with the dispatcher's decisions. Review disagreements rather than treating every manual override as resistance to automation.
Your acceptance set should include a sick technician, a late part, a cancelled customer visit, an urgent call and a job requiring two people. Test how many existing commitments change when each disruption arrives. Inspect the unassigned work and confirm that the explanation identifies a useful action for the dispatcher.
Measure completion within promised windows, avoidable repeat visits, planning effort and changes after publication. Agree how those measures are collected and what a meaningful improvement would look like for your team. Ask for the rule catalogue, integration contracts and a documented way to run the planner without the supplier's personal account.
The surrounding mobile process matters too. Our guide to offline collaboration and revoked access covers one operational edge, while API integration scoping helps define reliable input and acknowledgement boundaries.
TuniCyberLabs builds custom scheduling and operational tools. Bring a difficult day's plan and the reasons behind its assignments. That gives us a practical starting point for an optimisation pilot your dispatchers can evaluate.