Adding an optimization engine on top of BigChange

What BigChange documents about routing and scheduling

BigChange’s product pages describe the scheduler clearly and honestly. The vocabulary is workflow-first, route-second:

• Job Scheduling. “Drag jobs onto your team’s calendar and watch them appear instantly on mobile devices.” The route layer beneath it is described as: “calculate the fastest route between jobs while accounting for traffic, engineer skills, and vehicle equipment”.
• Multi-day and multi-engineer. “Create jobs that span multiple days and assign them to one or more engineers”; bulk drag-and-drop reassignment for hundreds of jobs.
• Recurring PPM. “Set up recurring service schedules for PPM work” with automatic generation at specified intervals.
• Documented outcomes. 11% less drive time, 10% time saved per job, 10% less fuel used (BigChange’s own benchmarks for the workflow product).

What none of those pages describe is a constraint-based optimization engine: an input model of jobs, engineers, vehicles, depots, skills, time windows, SLAs and recurring cadences, and a documented optimization API that produces assignments under an objective. That layer is not where BigChange competes. It is what eLogii adds.

Where drag-and-drop scheduling reaches its boundary

The pattern is consistent across operations where this comes up:

• Planner-as-optimizer. The planner spends the morning hand-balancing jobs across engineers, depots and skill sets. The route calculation between the jobs they place is fast and correct; the placement itself is the bottleneck.
• Multi-depot rebalancing. A regional contractor or distribution arm with three or four depots needs the optimizer to treat all depots as part of the same problem. BigChange treats depot as a per-engineer starting point, so cross-depot rebalancing is operator work.
• Recurring program at scale. Quarterly compliance, monthly PPM, weekly commercial maintenance: BigChange generates the schedule, but optimizing the generated stops under interacting SLAs and cadences is its own problem.
• Constraint-heavy commercial work. A two-engineer install over three days with a customer-confirmed start window, a skill that needs the same engineer back on day three, an overnight stop. The constraints are real and there are usually hundreds of jobs to satisfy them across.
• SLA-locked work mixed with flexible. The optimizer needs to protect the locked stops, balance the flexible ones, and re-optimize on the fly when a no-access comes in. Drag-and-drop catches up to this slowly.

At a glance: a 60-engineer regional contractor

A regional plumbing and heating contractor running three depots across the South-East. Sixty engineers in the field. Two planners. The book splits roughly 40% PPM under SLA contracts and 60% reactive call-outs that come in through phones, email and BigChange’s customer booking portal. BigChange covers the FSM workflow cleanly: JobWatch on the van, vehicle tracking, quoting and invoicing, BI dashboards, the Lightning agents writing pre-job briefs and post-job summaries.

The bottleneck shows up in the planning room each morning. The two planners spend an hour hand-balancing reactive against PPM, reconciling yesterday’s customer-booked slots against today’s actual routes, and working around the engineer off sick at depot 2 by manually moving stops to depots 1 and 3. The route calculation between assigned jobs is fast. The placement of those jobs is the bottleneck. Adding eLogii compresses that morning hour into a 10-minute review of a constraint-aware optimization run; BigChange continues to own everything else.

The workaround in BigChange and where it breaks

The workaround is the planner. BigChange’s drag-and-drop board is good at what it’s built for, and an experienced planner can carry a real operation on it. The friction shows up at scale: time spent on planning grows non-linearly with the number of engineers and depots; the bus-factor of the operation is the one planner who knows where everything goes; cross-day and cross-depot constraints get carried in heads and spreadsheets, not in the system. When the planner takes leave, planning quality drops visibly. When the operation grows past the planner’s capacity, the team adds a second planner, then a third, and the coordination tax climbs again.

None of this means BigChange is the wrong tool. It means there is an optimization layer below the scheduling board that BigChange does not claim to be, and eLogii does.

How eLogii’s optimization engine handles this

eLogii’s engine takes a constraint model as input and produces both assignments and routes as output. The planner steers it with rules they can see; the engineer executes the plan in the field app they already use.

• Two engines. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine takes more factors into account and is the choice for multi-depot, multi-day, long-haul and constraint-heavy operations.
• Three assignment modes. Optimize Everything (creates fresh routes including all assignments), Add to Routes, Keep Existing Assignments (incorporates new tasks while preserving driver assignments), and Add to Routes, Keep Existing Assignments and ETAs (inserts new tasks into available slots without modifying existing stop sequences or ETAs).
• Three load-balancing modes. Most Efficient Routes (fewest vehicles), Balance the Minimum Number of Routes (across load, time, distance or job count), and Use All Vehicles / Finish as Soon as Possible (maximize speed).
• REST-callable. All six modes are programmatic. Planners can lock specific routes, manually reorder stops, or re-run with new constraints. The optimizer is not a black box.
• Rule-based re-optimization. Re-route a no-access visit to the nearest engineer with the right skill, without moving any customer-confirmed slots in the next 90 minutes. Visible to the planner.

How the integration sits with BigChange

BigChange stays in place as the system of record. The connector between the two products is custom-built; there is no published eLogii-BigChange integration on either side. BigChange exposes a RestAPI module under the “Extras” section of its plan (paid add-on alongside the Standard or Plus license tier), and eLogii’s REST API has 70+ endpoints including the optimization endpoints. The flow:

1. Read from BigChange. eLogii reads jobs, customers, engineers, vehicles, depots and skill sets from BigChange’s RestAPI. Recurring PPM templates flow in alongside the daily job queue.
2. Optimize in eLogii. The run produces routes with assignments, start times, end times, overnight stops, depot start/end, SLA respect and recurring-cadence respect. Planner reviews in eLogii’s dispatch desk or accepts an Auto run.
3. Write back to BigChange. Routes and ETAs are written back to BigChange. JobWatch picks up the planned assignments. Completion data flows back to BigChange for invoicing, BI and Lightning agent context.
4. Engineer experience unchanged. The engineer opens BigChange’s JobWatch app on site. The routing underneath is the one eLogii planned.

Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the multi-depot regional book, a recurring-service program, or the business unit where BigChange’s drag-and-drop is leaking the most.

Frequently asked questions

Does BigChange have an optimization engine?

BigChange has a route calculation feature in its scheduler. The product page describes it as: “calculate the fastest route between jobs while accounting for traffic, engineer skills, and vehicle equipment”. The verb is “calculate the fastest route between jobs” – it optimizes the route after the planner has assigned them via drag-and-drop. What BigChange’s published docs do not describe is a constraint-based optimization engine that takes jobs, engineers, vehicles, depots, skills, time windows and SLAs as inputs and produces the assignments themselves. That layer is what eLogii adds.

What is the difference between BigChange’s route calculation and an optimization engine?

Route calculation: given assignments, find the fastest path between the stops. Optimization engine: given a constraint model (skills, capacity, time windows, SLAs, depots, recurring cadences, cross-day dependencies), produce the assignments that minimize or maximize an objective (drive time, vehicles used, balance across crews). BigChange does the first inside the scheduler. eLogii does both, exposed as a REST API. The two layer cleanly: BigChange keeps the scheduling board, mobile app, vehicle tracking and FSM workflow; eLogii sits underneath as the engine the planner doesn’t have to be.

When is BigChange’s built-in scheduler enough?

When the planner can comfortably make the assignments by hand and BigChange’s route calculation between them is the optimization layer the operation needs. This covers a wide band of UK trade and field service work: plumbing, HVAC, fire and security, facilities management, electrical, equipment hire, drainage and waste. BigChange’s published outcomes (11% less drive time, 10% time saved per job, 10% less fuel) reflect that workflow well. Where the operation outgrows it is the optimization layer underneath – when assignment becomes a constraint-satisfaction problem rather than a planner judgement call.

How does eLogii’s optimization engine integrate with BigChange?

Custom integration against both products’ REST APIs. BigChange exposes a RestAPI module that customers add to their plan; eLogii’s REST API has 70+ endpoints including the optimization endpoints, ApiKey auth and a full-parity sandbox. Once the connector is built: eLogii reads jobs, engineers, vehicles and depots from BigChange, runs the optimization, writes optimized routes and ETAs back to BigChange. The engineer opens the JobWatch app on site; the route underneath is the one eLogii planned.

What does eLogii’s optimization engine look like in product terms?

Two engines and six configurable modes, all REST-callable. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine handles multi-depot, multi-day, long-haul and constraint-heavy operations. Three assignment modes: Optimize Everything, Add to Routes Keep Existing Assignments, Add to Routes Keep Existing Assignments and ETAs. Three load-balancing modes: Most Efficient Routes, Balance the Minimum Number of Routes, Use All Vehicles / Finish as Soon as Possible. Each is callable programmatically and visible to the planner as a control they can see and steer.