BigChange JobWatch scheduler: design ceilings and the optimization layer underneath

What BigChange does well, taken on its own terms

BigChange’s product is built around an all-in-one job management workflow:

• CRM and job lifecycle. Customer records, quotes, invoices, payments, job cards, mobile execution via JobWatch, vehicle tracking, BI dashboards, the Lightning AI agent layer (JustAsk, JobReady, JobScribe, FieldReady, JobBrief), Network module for subcontractors.
• Drag-and-drop scheduling. “Drag jobs onto your team’s calendar and watch them appear instantly on mobile devices.”
• Route calculation between assigned jobs. “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.”
• Recurring PPM. “Set up recurring service schedules for PPM work.”
• Customer booking. Online customer booking portal with capacity-aware slots.
• Documented outcomes. 11% less drive time, 10% time saved per job, 10% less fuel used.

For a wide band of UK trade and field service operations, this is exactly the right product. Plumbing, HVAC, fire and security, facilities management, electrical, equipment hire, drainage and waste: BigChange covers them end to end. The friction is in a specific layer underneath the scheduler, not in the scheduler itself.

Four patterns where the scheduler reaches its design ceiling

Each pattern has its own dedicated sub-page in this cluster. Here they are in one view:

• Optimizer-driven assignment. BigChange’s scheduler calculates the fastest route between jobs once the planner has placed them. When the planner is spending the morning hand-balancing jobs across engineers, depots and skill sets, the layer that needs to fill in is the optimization engine: a constraint-based assignment that takes jobs, engineers, vehicles, depots, skills, time windows and SLAs as inputs and produces the assignments under an objective. That layer is what eLogii adds.
• Multi-depot rebalancing. BigChange treats depot as a per-engineer starting point. Regional contractors with three or four depots, distribution arms with branch networks, and recurring programs across regions need the optimizer to treat all depots as a single problem. The output is one consistent plan across depots, not the sum of per-depot plans.
• Recurring service programs at scale. BigChange’s scheduler generates recurring PPM schedules. At thousands of recurring stops with SLAs varying by customer or contract, with cadence drift to keep capacity balanced, schedule generation is no longer the same thing as optimization. The optimizer needs to model task and route template groups as constraint inputs, balance recurring against reactive, and protect SLA-locked stops.
• Route-aware slot booking. BigChange’s Standard plan includes an online customer booking portal with capacity-aware slots. The booking surface stays in BigChange. What changes when route-aware availability is added underneath: slots offered to customers fit the current optimized plan, failed visits drop materially, and customer-driven reschedules can be handled without coordinator involvement.

Each pattern is addressable on its own. Most operations start with whichever is leaking the most.

How to tell if your operation has hit one of them

The diagnostic signals are operational, not headcount-based. Some patterns from operations that have moved to a combined BigChange + eLogii stack:

• The planner has become the optimizer. The planner spends the morning hand-balancing rather than reviewing. The bus-factor of the planning operation is one or two people.
• SLA misses are concentrated in specific programs or depots. The recurring book or the regional book is leaking against SLAs; the rest of the operation is fine.
• Cross-depot capacity drift. One depot runs hot, another runs underused, drive time creeps up. No one has time to spot it in real time.
• High failed-visit rate from customer-booked slots. Slots offered through the booking portal break the day when reconciled. Coordinator escalations rise.
• Reschedules need a coordinator. Most customer-driven reschedules end up handled by someone in the office because the slots offered don’t fit the optimized plan.
• Planning time grows faster than the operation. Doubling the engineer count more than doubles the planner load.

Each of these is a signal that the optimization layer underneath the scheduler is the bottleneck. The right answer is to add the engine, not to rebuild the FSM workflow.

At a glance: an 80-engineer multi-service contractor

A multi-service contractor running plumbing, HVAC and electrical across a regional book. Eighty engineers in the field, four depots, two planners. Roughly 50% PPM under SLA contracts, the rest reactive work coming in through phones, email and BigChange’s customer booking portal. All four patterns hit at once.

Each pattern shows up in a specific place. The optimizer-driven assignment pattern shows up in the planning room each morning: two planners hand-balancing the daily mix instead of reviewing an optimized plan. The multi-depot rebalancing pattern shows up when an engineer at depot 3 is off sick and the day’s reactive work has to be redistributed to depots 1, 2 and 4 by hand. The recurring-program optimization pattern shows up as creeping SLA misses on the quarterly compliance book; the schedule was generated correctly, the routing between stops wasn’t the bottleneck, but the interaction between PPM and reactive across the same engineers was. The route-aware slot booking pattern shows up as a steady 6–8% failed-visit rate on portal-booked work, with coordinators absorbing the reconciliation. Each pattern is addressable on its own. Operations at this shape most often start with whichever is leaking the most visible cost, then expand on the same integration.

What eLogii adds, in one place

The optimization engine that runs underneath BigChange’s scheduler:

• Two engines. Default engine for high-throughput daily planning (100 tasks in under 10 seconds). Advanced engine for multi-depot, multi-day, long-haul and constraint-heavy operations.
• Six configurable modes. 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).
• Multi-day, multi-depot, multi-engineer in one run. Single optimization across the routing horizons BigChange’s scheduler is not designed to solve.
• Task and route template groups. Weekly, monthly, quarterly and bespoke cadences modeled directly as constraint inputs.
• Rule-based re-optimization. Operator-visible rules; live re-optimize while protecting locked SLAs and customer-confirmed slots.
• Slot booking co-pilot. Route-aware availability that returns only slots that fit the current optimized plan.
• REST-callable. All six modes plus slot availability plus optimization triggers exposed as REST endpoints. Seven webhook events including live driver GPS and Route ETAs Update.

How the integration sits with BigChange

BigChange stays the system of record for the FSM workflow. The connector between the two products is custom-built; there is no published eLogii-BigChange integration on either side.

1. Read from BigChange. eLogii reads jobs, customers, engineers, vehicles, depots, skill sets and recurring PPM templates from BigChange’s RestAPI module.
2. Optimize in eLogii. The run produces assignments and routes under the chosen objective, respecting SLAs and customer-confirmed slots.
3. Write back to BigChange. Optimized routes and ETAs flow back. JobWatch picks up the assignments unchanged.
4. Engineer experience unchanged. The engineer opens BigChange’s JobWatch app. The routing underneath is the one eLogii planned.

Most teams complete the connector build in 3 to 5 weeks. The most common first wave is whichever of the four patterns is leaking the most.

Frequently asked questions

Where does BigChange’s drag-and-drop scheduler reach its design ceiling?

Four patterns. First, optimizer-driven assignment: when the planner needs to decide assignments under hundreds of competing constraints, not place jobs by drag-and-drop. Second, multi-depot rebalancing: when work needs to flow between three or four depots based on capacity, skill and SLA. Third, recurring service programs at scale: thousands of recurring stops with interacting SLAs and cadences. Fourth, route-aware slot booking: when slots offered to customers should fit the current optimized plan, not just nominal capacity. Each of these is a different layer of the same problem – the optimization engine underneath the scheduler.

Does this mean BigChange is the wrong tool?

No. BigChange is the all-in-one FSM workflow for UK trades and field service. The scheduler is excellent at what it’s built for: drag-and-drop assignment by an experienced planner, route calculation between assigned jobs, mobile JobWatch execution, vehicle tracking, financials and BI in one product. For a wide band of operations, that is exactly the right tool. eLogii is not an FSM. It is the routing and optimization engine for operations where the optimization layer underneath the scheduler is the bottleneck.

How do I know if my operation has outgrown BigChange’s scheduler?

Diagnostic signals: the planner spends the morning hand-balancing rather than reviewing; SLA misses are concentrated in specific programs or depots; the bus-factor of the planning operation is one or two people; reschedules from customers regularly break the day; cross-depot work feels like it should be balanced more but no one has time to look. Each is a sign that the assignment problem has grown past what drag-and-drop is designed to solve. Adding eLogii is the answer to that specific layer; BigChange keeps doing everything else.

How does the integration work?

Custom integration against BigChange’s RestAPI module and eLogii’s REST API. eLogii reads jobs, customers, engineers, vehicles, depots, skills, recurring templates from BigChange; runs the optimization across the chosen layer (multi-depot, recurring program, slot booking, all of them); writes optimized routes and ETAs back to BigChange. JobWatch picks up the assignments unchanged. Completion data flows back to BigChange for invoicing, BI and Lightning agents. Typical connector build: 3 to 5 weeks.

Can I start with just one of these layers?

Yes, and that is how most teams start. The most common first wave is whichever layer is leaking the most: multi-depot rebalancing for regional contractors, recurring program optimization for facilities and compliance books, route-aware slot booking for high-reschedule operations, optimizer-driven assignment for any operation where the planner is the bottleneck. Once one layer is live and the lift is visible, the others follow on the same integration.