The real bottleneck wasn't logistics. It was decision making.

Every morning started the same way.

Hundreds of new service tickets arrived in GLPI. Many of them required a physical visit—collecting equipment, delivering replacement devices, transporting documents, or performing on-site maintenance.

On average, the company received 250–350 tickets every day.

Not every ticket required a driver, but enough did to keep one dispatcher occupied for 2–3 hours every morning.

Their job looked deceptively simple:

  • review incoming tickets;
  • identify locations;
  • understand driver availability;
  • estimate workloads;
  • assign tickets.

In reality, it was a continuous optimization problem solved manually.

As ticket volume grew, the process became increasingly difficult.

Drivers occasionally ended up serving customers on the same street while another area of the city remained untouched until the afternoon.

Some routes were unnecessarily long.

Some requests had to wait simply because nobody could evaluate hundreds of locations simultaneously.

The dispatcher wasn't making poor decisions.

The problem was that humans are not route optimization algorithms.

Buying another logistics platform wasn't the answer

Many companies would solve this by introducing dedicated dispatching software.

I chose a different approach.

The business already had a system that contained everything needed for planning:

  • customer addresses;
  • ticket priorities;
  • scheduled dates;
  • service information;
  • assigned departments.

That system was GLPI.

Instead of replacing the workflow, I extended it.

The result was a custom plugin that transforms incoming tickets into an optimization problem and automatically assigns drivers.

System Architecture

The overall workflow is intentionally simple.

GLPI
  │
  ▼
Collect dispatch tickets
  │
  ▼
Geocode addresses
  │
  ▼
Build travel-time matrix
  │
  ▼
Optimize routes (Google OR-Tools)
  │
  ▼
Assign drivers
  │
  ▼
Update GLPI tickets

No separate logistics portal.

No duplicated databases.

The dispatcher simply presses one button.

Location data is harder than it looks

Addresses entered by people are rarely perfect.

Different abbreviations. Typos. Missing building numbers. Different formatting.

Before any optimization could happen, every address had to become precise geographic coordinates.

To make this reliable while keeping API costs low, I implemented a hybrid geocoding pipeline.

The system first checks a local SQLite cache. If the address has already been processed, coordinates are returned instantly.

Otherwise:

  • Google Geocoding API is used as the primary provider;
  • Photon (OpenStreetMap) serves as an automatic fallback;
  • a rate limiter protects public services from excessive requests.

After several months in production, most requests are now resolved directly from cache, reducing both execution time and API usage.

Route Optimization Results Map

Route optimization results and visualization for drivers in Kyiv

Optimizing routes instead of guessing them

Once every destination has coordinates, the problem becomes mathematical.

Google OR-Tools models it as a Vehicle Routing Problem (VRP). The objective is not simply finding the shortest route — real logistics contains constraints.

The optimizer must respect:

  • Driver working hours: planning shifts within set windows, e.g., from 9:30 to 17:30.
  • Lunch breaks: a mandatory rest window that the algorithm automatically schedules at the best time.
  • Depot departure and return: all routes are cyclic, starting and ending at the company's central Depot.
  • Customer time windows & priorities: respecting client availability slots and ticket urgency levels.
  • Service duration: factoring in the actual time required to perform the service at each location.

Travel times are calculated using a self-hosted OpenRouteService instance built on OpenStreetMap data, allowing routing decisions to reflect actual road networks instead of straight-line distances.

One particularly useful OR-Tools feature is Disjunctions with Penalties.

In real life, there are days when the available drivers simply cannot complete every request.

Rather than producing an impossible schedule, the optimizer automatically postpones the least important tasks while still generating a valid plan for everything else.

This closely matches how an experienced dispatcher would think—but produces consistent results every time.

For global optimization, the solver is configured with the Tabu Search metaheuristic and a PARALLEL_CHEAPEST_INSERTION first solution strategy.

Additionally, the mathematical model of OR-Tools supports easy scaling. With minimal configuration changes, it can factor in vehicle capacity and payload restrictions (Capacity Constraints) for shipping bulkier items.

From hours to minutes

Once optimization is complete, drivers are assigned automatically inside GLPI. The dispatcher reviews the result instead of building it manually.

After more than six months in production, the improvements have been significant:

Metric Before After
Daily planning 2–3 hours ~2 minutes
Ticket assignment Manual Automatic
Missed requests Occasional Eliminated
Route quality Experience-based Algorithmically optimized
Fuel usage Higher Reduced
Planning consistency Depended on dispatcher Consistent

The logistics team now spends its time dealing with exceptions instead of repetitive planning.

The biggest lesson

This project was never about Google OR-Tools. It was never about OpenStreetMap. And it certainly wasn't about writing another GLPI plugin.

The real value came from identifying a repetitive business decision and turning it into software. Every morning, one person had been solving the same optimization problem by hand. The algorithm simply became better at doing that job.

Automation is most valuable when it removes repetitive decisions rather than repetitive clicks.

Useful Links