navigate openesc close
Book a demo

In development

The route plan a dispatcher can’t build by hand.

We are building the Optimizer, a routing engine for Dimonoff | SCMS that turns today’s open work orders into a crew-by-crew schedule — respecting every certification, vehicle, part and time window at once, in seconds rather than a dispatcher’s morning.

In development — not yet available

The Dimonoff/Vectanor asset platform the Optimizer is being built on top of — this preview shows the asset map, not the Optimizer’s own routing screen.

Why this is a hard problem

Every morning a lighting or utility department faces the same question: given the open jobs, the crews who showed up, the trucks in the yard and the parts on the shelf, what is the best way to spend today? Answered by hand, this becomes a dispatcher grouping tickets by neighbourhood and sequencing them by instinct — a workable day, but rarely the best one, and there is no way to know how far from best it was.

The number of possible answers explodes far faster than intuition suggests: a single crew with 15 stops already has 1.3 trillion possible sequences. At 25 stops, checking every ordering at a billion per second would take roughly 490 million years — for one crew, before certifications, time windows or parts are even considered.

How it works, at a glance

The Optimizer reads directly from the systems already running the operation — no re-keying, no parallel spreadsheet.

  1. Reads the real picture

    Open work orders from WOM, asset condition and live alarms from SCMS, real stock by warehouse and by truck, and who is working today, in which vehicle, with which certifications.

  2. Builds a first legal plan in milliseconds

    A construction step assembles a complete, constraint-respecting schedule almost instantly — legal, but not yet the best available.

  3. Improves it for as long as it is given

    It then searches millions of candidate schedules against every hard constraint (skills, equipment, parts, time windows, shift limits) and soft trade-off (SLA risk, overtime, workload balance), keeping every change that scores better.

  4. Re-solves when the day changes

    A job runs long, a technician calls in sick, SCMS raises an emergency alarm — the Optimizer re-plans around what is already done and issues revised routes to crews still in the field.

What it is built to change

Design targets from the current build — not yet measured against a live customer deployment.

  • Shorter, denser routes

    Built to cut travel time and distance per intervention by an estimated 15–25%

  • Constraint-aware assignment

    The right crew, truck and part on the first visit, aimed at reducing costly repeat trips

  • Explicit trade-offs

    SLA compliance, cost and crew balance resolved by weights a manager sets and can defend, not by unwritten judgement

  • Overtime discipline

    Overtime priced into the plan itself and used only when the alternative costs more

  • Continuous re-planning

    Emergencies absorbed without discarding the rest of the day’s schedule

Only as good as the data underneath it

The Optimizer’s plans are only as accurate as its estimate of how long each job actually takes — which is why it is built to close the loop with WOM: every job closed in the field records real arrival time, real duration and real parts used, and those actuals recalibrate tomorrow’s estimates. That is also why the Optimizer is being developed as part of the same workflow as WOM, not as a separate add-on.

More on the way

The Optimizer isn’t the only thing in development. Two more SCMS capabilities are taking shape.

  • In development

    Fixed before the truck rolls

    A flagged fault won’t have to wait for tomorrow’s report anymore. We’re building automatic remediation into SCMS: the system will attempt a remote fix itself the moment a point drifts out of range, and only calls on support once sending a crew is genuinely the only option left.

    • Fewer truck rolls for faults that can be resolved remotely.
    • An intervention list that reflects the fleet’s real condition, not a backlog of past alerts.
    • Support receives a diagnosis, not just a symptom.
  • In development

    A grid outage, not a lighting fault

    A neighbourhood power outage shouldn’t read as a wave of streetlight failures. We’re building a feature that automatically tells a grid outage apart from a real equipment fault — and can flag utility-planned interruptions before they even start.

    • Fewer false alerts after a power outage or a planned utility interruption.
    • The explanation appears right on the affected point, inside the tool your crews already use.
    • Support time goes to the faults that are actually theirs to fix.

Want to see where this is headed?

Tell us about your crews and your service area, and we will walk you through what the Optimizer is being built to do for a network like yours.

Talk to us about it