Régionnement des services sur le terrain : LBBD a relevé 202 de 210 objectifs

The best results come from combining a constraint-aware optimisation engine, continuous event-driven rescheduling and balanced workload rules rather than relying on any single method alone. Operations teams that adopt this combination typically see measurable travel-time reduction, stronger SLA attainment and higher technician utilisation. Platforms in the field service management category are built to apply exactly this combination in daily operations.

En bref

• Exact algorithms like LBBD outperform metaheuristics in solving large, constrained scheduling instances closer to the optimal solution, especially for high-value jobs.
• Real-time traffic, telematics, and incident data are essential for dynamic rerouting and improving dispatch accuracy during daily operations.
• Successful routing implementation requires integrating static data such as job addresses, durations, skills, and vehicle capacity, with live feeds and regulatory cost factors.
• Incremental, event-driven changes build technician trust more effectively than overnight system overhauls, maintaining operational consistency.
• Balancing workload, technician preferences, and travel time share is crucial to sustaining productivity and technician satisfaction over optimizing solely for distance.

Table des matières

• What is the technician routing and scheduling problem?
• Which algorithms actually solve technician routing problems?
• What data does reliable routing optimisation need?
• How do you design, pilot and scale a routing programme?
• What should you look for in a routing platform?
• How FullyOps supports these routing practices
• Where routing programmes go wrong
• Get started with FullyOps
• Sources
• FAQ

What is the technician routing and scheduling problem?

The technician routing and scheduling problem, often shortened to TRSP, asks a deceptively simple question: which technician should visit which job, in what order, and at what time. In practice, the answer depends on a set of constraints that interact with each other in ways that make manual planning unreliable once a business grows past a handful of technicians.

A workable TRSP model needs to account for several operational realities at once. Time windows set by customers or contracts limit when a visit can happen. Skills and certifications determine which technicians can legally or practically perform which job. Service times vary by job type and, often, by technician experience. Vehicle capacity and equipment constraints limit how many jobs or how much stock a technician can carry in a day. Working-hour rules cap the length of a shift and the breaks required within it. Job priorities, particularly for emergency or contractual SLA work, override pure distance logic.

• Time windows: customer-agreed or contractual slots that a visit must fall within.
• Skills and certifications: matching technician qualifications to job requirements before distance is even considered.
• Service durations: realistic estimates per job type, adjusted for technician experience where possible.
• Vehicle and inventory capacity: what a technician can physically carry or complete in one run.
• Working-hour and break rules: legal and contractual limits on shift length and rest periods.
• Job priority: emergency call-outs and SLA-bound work that must jump the queue.

A second distinction matters as much as the constraint list itself: static planning versus dynamic, day-of dispatching. Static planning builds the next day’s or week’s schedule in advance, based on known jobs and available technicians. Dynamic dispatching reacts to what actually happens during the day: a job overruns, a technician calls in sick, an emergency ticket arrives. Both matter. A schedule that looks optimal on paper but cannot absorb a single delay without falling apart is not an operational plan, it is a spreadsheet exercise.

The KPIs chosen to judge routing quality should reflect this dual reality rather than a single number. Travel time as a share of total working time shows how much of a technician’s day goes to windscreen time rather than billable work. Technician utilisation measures how much of the available capacity is actually deployed against demand. SLA attainment tracks whether time-critical jobs are met within their contractual window. First-time fix rate reflects whether the right technician, with the right skills and parts, was sent in the first place. Overtime hours flag whether the schedule is structurally too tight, masking a capacity problem rather than a routing one.

Getting these definitions right before choosing an algorithm avoids the common mistake of optimising a metric that does not actually reflect operational health.

Which algorithms actually solve technician routing problems?

Once the problem is defined, the choice of solving method has a direct effect on schedule quality, computation time and how confidently a business can trust the output. Three broad families dominate practice: exact decomposition methods, metaheuristics, and simpler rule-based heuristics.

Logic-Based Benders Decomposition, or LBBD, is one of the more rigorous exact approaches used in academic and applied technician-routing research. It works by splitting the problem into a master problem, typically the assignment of technicians to jobs, and a set of subproblems that check feasibility, such as whether a given route respects time windows and working hours. When a subproblem fails, it feeds a constraint back into the master problem, which then searches again. This loop lets LBBD handle large, constrained instances that overwhelm simpler exact methods.

**A CIRRELT 2026 study found that an LBBD approach solved the majority of benchmark instances to optimality, outperforming a standard Branch-and-Cut method in terms of solved instances and optimality gap. That gap size explains why exact decomposition methods are gaining ground in technician-routing research: a smaller gap means the schedule produced is closer to the true best possible allocation of technicians to jobs.

Metaheuristics, including genetic algorithms and various local search methods, take a different route. Rather than proving optimality, they search a large solution space quickly and converge on a good, though not guaranteed-best, schedule. They tend to suit environments with very large numbers of daily jobs and technicians, where an exact method’s computation time becomes impractical, or where the constraint set changes too often to justify a heavier exact model.

• LBBD and other exact decomposition methods: best where schedule quality has a direct financial or contractual cost and computation time budgets allow for a longer solve.
• Genetic algorithms and local search metaheuristics: best for large-scale daily replanning where speed matters more than provable optimality.
• Rule-based heuristic dispatch: fastest of the three, useful for smaller operations or as a fallback when live conditions change faster than any solver can recompute.

The practical trade-off is compute time against solution quality. A useful operational threshold is to reserve exact or near-exact methods for baseline planning runs, done overnight or weekly, and to lean on heuristics or metaheuristics for intraday adjustments where a result is needed in seconds rather than minutes. Whichever family is used, the model only stays honest if it accounts for technician skill variation, realistic (and where possible technician-specific) service time estimates, and explicit feasibility checks rather than assuming every route that looks short on a map is actually deliverable on the ground.

What data does reliable routing optimisation need?

An optimisation engine is only as good as the data feeding it, and technician routing has both static and live components that need to be in place before any algorithm can be trusted with real schedules.

The static layer is the foundation: accurate job addresses, job types and their typical service durations, skill tags per technician and per job, and vehicle or van capacity limits. Without this baseline, even the most rigorous algorithm optimises against fiction.

Live data is what turns a planning tool into an operational one. Real-time traffic and incident feeds let the system react to a motorway closure or unexpected congestion rather than dispatching against yesterday’s travel times. In practice, this means integrating road transport information such as RTTI (Real-Time Traffic Information) and road-safety data. NAP Portugal, the national access point coordinated by IMT, provides registered access to this kind of traffic, road-safety and safe-stop data, with some datasets exposed through APIs for automated extraction. Telematics feeds and technician GPS positions complete the live picture, allowing dispatchers to see where every vehicle actually is rather than where the plan assumed it would be.

Regulatory and cost inputs deserve their own line in any data specification, because they change what “optimal” actually means. Toll costs, known locally as portagem, vary by vehicle class and route, and IMT’s portagem guidance sets out the relevant discount regimes and eligibility rules that affect the true cost of a given route, not just its distance. On the regulatory side, Decreto-Lei n.º 110/2026 coordinates the national implementation of intelligent transport services and clarifies IMT’s role in making certain transport data available, alongside the privacy safeguards that apply to that data. Working-hour rules, meanwhile, cap shift length and set mandatory rest periods that any schedule has to respect before it respects distance.

1. Compile the static dataset first: addresses, job durations, skills and vehicle capacity, validated against real job history rather than assumptions.
2. Register for live traffic and road-safety feeds through NAP Portugal and confirm which datasets expose an API for automated ingestion.
3. Map toll and working-hour rules into the cost model so that routing decisions reflect real operating cost, not just kilometres.
4. Connect telematics and technician GPS feeds so dispatch decisions use live vehicle position rather than the last known plan.
5. Build integration endpoints into CRM, ERP, inventory and HR or roster systems so job data, stock levels and technician availability stay synchronised automatically.

Conseil de pro : Treat the integration list as a dependency chain: a routing engine with perfect algorithms but a stale skills table or an unsynchronised roster will still produce bad schedules.

Integration endpoints matter as much as the data itself. A routing engine that cannot talk to the CRM will misjudge job priority; one that cannot see inventory will send a technician to a job without the part they need; one disconnected from HR or roster systems will schedule someone who booked leave. Ticketing system integration closes the loop by feeding new and updated jobs back into the live plan as they arrive, rather than waiting for the next planning cycle.

How do you design, pilot and scale a routing programme?

A routing programme succeeds or fails on the discipline of its rollout, not on the sophistication of its algorithm. The steps below reflect what tends to separate a pilot that becomes a permanent operating model from one that quietly gets abandoned after a few weeks.

Start with a baseline. Before changing anything, measure the current travel-time share (the proportion of a technician’s paid hours spent driving rather than working) and current technician utilisation (the proportion of available capacity actually assigned to jobs). Without this number, no improvement claim later has anything to compare against.

1. Select a pilot territory: choose one region or team large enough to be representative but small enough to manage closely, typically a single depot or service area.
2. Set a sample size and duration: run the pilot for enough weeks to smooth out normal daily variation, generally four to eight weeks depending on job volume.
3. Define success criteria up front: agree the target movement in travel-time share, SLA attainment and utilisation before the pilot starts, not after seeing the results.
4. Test algorithm settings deliberately: compare at least one exact or near-exact planning run against a heuristic dispatch setting to see which fits the pilot’s job mix.
5. Review and decide: use the agreed criteria, not anecdote, to decide whether to expand, adjust or stop.

Rollout beyond the pilot needs its own checklist, separate from the pilot’s own success metrics.

• Technician training: cover both the mobile app and the reasoning behind reassignments, since resistance often comes from not understanding why a route changed.
• Exception-handling rules: define in advance what happens when a job overruns, a technician is unavailable, or an emergency ticket arrives mid-route.
• Governance and KPI cadence: set a fixed review rhythm, weekly at first, monthly once stable, to track the core KPIs against target.
• Continuous tuning: revisit algorithm parameters as job mix, technician headcount or service area changes, rather than treating the initial configuration as permanent.

Daily operations then run as a live orchestration exercise. Event-driven rescheduling means the plan updates when a real event happens (a job finishes early, a new emergency ticket lands, a technician reports a delay) rather than waiting for the next full replan. Clear escalation paths, so a dispatcher knows exactly when to override the system rather than wait for it to catch up, keep this responsive without becoming chaotic. Our guide de planification des interventions sur site sets out a fuller version of this playbook for teams building it from scratch.

What should you look for in a routing platform?

Choosing a platform on the strength of its marketing claims is a common and costly mistake. The functional checklist below focuses on what actually determines whether a tool holds up under real operational load.

• A genuine constraints engine: capable of modelling time windows, skills, vehicle capacity and working-hour rules simultaneously, not as bolt-on filters.
• Skills-based matching: automatic filtering of technicians by certification and competency before distance is even calculated.
• Real-time rescheduling: the ability to reprocess the day’s plan when a job overruns or an emergency ticket arrives, without a full manual rebuild.
• A usable mobile app: technicians need to see their route, log time and update job status from the field, not just receive a printed sheet.
• Reporting that ties back to KPIs: travel-time share, utilisation and SLA attainment should be visible without a manual spreadsheet exercise.

Integration checklist items matter just as much as the features above. Confirm what APIs the platform offers for telematics, HR or roster systems, inventory and CRM, and ask specifically how job updates flow both ways rather than only into the platform. A tool that ingests CRM data but cannot push status updates back out creates exactly the kind of blind spot event-driven rescheduling is meant to eliminate.

Operational ergonomics deserve attention too. Supervisors need visible controls, including a clear way to manually override an automated suggestion, because no algorithm should have the final word on every judgement call a dispatcher makes on the ground. Ask what compute-time SLA the vendor commits to for a full replan, since a system that takes minutes to recalculate a route during a live emergency has effectively failed at its job.

Conseil de pro : Ask any vendor for their compute-time SLA on a full daily replan, not just an average case: that number tells you how the system behaves on the busiest day of the month, which is the day that matters most.

Non-functional concerns round out the evaluation: how data is stored (single or multi-tenant), whether data residency requirements are met, what support SLAs apply once live, and whether deployment can flex between cloud and hybrid depending on the organisation’s IT policy. Our Field Service Management overview sets out how these functional and non-functional areas typically map onto a platform’s feature set.

How FullyOps supports these routing practices

FullyOps is built around the same operational logic this guide describes: structured work-order management, technician workflows and reporting that ties scheduling decisions back to real KPIs. Work orders carry the job details, skill requirements and status updates that a constraints-aware routing model depends on, and technician-facing tools capture time logs and intervention records that feed utilisation and SLA reporting.

A platform’s work-order management gives each job structured data (type, priority, required skills) that routing decisions need as input. Intervention tracking and hours logging feed utilisation and SLA metrics, while operational reporting turns those logs into travel-time and utilisation figures a routing programme should review regularly.

Readers building or refining a rota structure can find practical detail in our technician rota resources, which cover shift constraints and rostering alongside the scheduling logic discussed here. The field service scheduling guide referenced earlier extends this into a fuller planning template for teams ready to move from theory to an operating procedure.

Where routing programmes go wrong

The most common failure is the rip-and-replace approach: scrapping the existing schedule and imposing a fully automated one overnight. Technicians lose trust the moment the new system sends them somewhere the old rota never would have, and dispatchers stop trusting a tool they do not understand. Incremental, event-driven change, where automation earns trust by handling exceptions well before it takes over full planning, holds up far better in practice.

A second, quieter mistake is optimising for distance alone. A schedule that minimises kilometres but hands one technician a punishing run of back-to-back emergency jobs while another sits idle will not survive contact with a workforce for long. Balanced scheduling, workload fairness, mandatory breaks and a channel for technician preference all matter as much as the shortest route on the map.

Conseil de pro : Set a maximum travel-time-share threshold per technician per day and flag any schedule that breaches it before it goes live, rather than discovering the imbalance in next month’s turnover figures.

— Pedro

Get started with FullyOps

Turning this guide into daily practice means fewer manual spreadsheets and less time reconciling job status across disconnected tools. Some platforms bring work-order management, technician scheduling and mobile field operations into one platform, so a dispatcher’s reschedule, a technician’s status update and a manager’s utilisation report all draw from the same live data rather than three separate systems.

• Request a demo to see how work orders, scheduling and mobile logging connect in practice.
• Compare plan tiers, Basic, Professional and Advanced, on the FullyOps site to find the fit for your team size and feature needs.

Pricing for each plan is available on request through the FullyOps team.

Sources

• CIRRELT-2026-11: Technician routing and scheduling with LBBD
• NAP Portugal — IMT
• Taxas de portagem — Instituto da Mobilidade e dos Transportes
• Decreto-Lei n.º 110/2026

FAQ

What is technician routing and scheduling in field service?

Technician routing and scheduling is the process of assigning field technicians to jobs and sequencing their visits to respect time windows, skills and working-hour rules. It balances travel time against service quality, aiming to keep technicians productive while meeting customer commitments.

Which algorithm is best for technician routing optimisation?

There is no single best algorithm for every operation: exact decomposition methods like LBBD suit smaller, high-value job sets where schedule quality justifies longer computation, while genetic algorithms and other metaheuristics suit larger, fast-changing daily volumes. A CIRRELT 2026 study found LBBD solved 202 of 210 benchmark instances to optimality against 161 for Branch-and-Cut, illustrating the quality gain exact methods can offer where compute time allows.

How does real-time traffic data improve technician routing?

Real-time traffic and road-safety feeds let a routing system adjust routes as conditions change, rather than dispatching against outdated travel-time assumptions. In practice, this means integrating sources such as NAP Portugal, which provides registered access to RTTI and road-safety data, some of it available through API.

Does FullyOps support technician scheduling and rota management?

FullyOps includes work-order management, technician workflows and reporting features that support scheduling, intervention tracking and rota planning. Details on rota-specific tools are available through the technician rota resources on the FullyOps site.

What data do I need before implementing routing optimisation?

At minimum, you need accurate job addresses, service durations, technician skill tags and vehicle capacity as static inputs, alongside live traffic, telematics and technician location feeds. Regulatory inputs such as toll rules from IMT’s portagem guidance also affect true routing cost and should be included in the model.

Recommandé

• Gestion des services sur le terrain : Optimiser et accroître l'efficacité
• Conseils d'optimisation des interventions sur le terrain : 5 stratégies pour l'efficacité
• Comment améliorer l'efficacité des services sur le terrain : 42% de temps d'arrêt en moins