BigChange and route-aware slot booking

What BigChange documents about customer booking

BigChange’s pricing page lists the “Online customer booking portal” as a Standard-plan feature, alongside quote and invoice creation, job card management and BI dashboards. The booking portal is the customer-facing surface: branded, hosted, integrated with BigChange’s scheduling data. The slots it offers come from BigChange’s capacity model.

What the published pages don’t describe is route-aware availability as a slot source: a calculation that asks, given the current optimized plan, which of the technically-available slots would the optimizer accept without breaking other commitments. Capacity availability and route-aware availability are different sets. The first answers “is there an engineer free?” The second answers “can this slot be honoured without dropping another one?”

Where capacity-aware slot booking reaches its boundary

The shape of operation where the difference starts to matter:

• Time-window-dense work. Many customers want narrow arrival windows. Capacity-aware booking can offer a 13:00-15:00 slot that nominally fits an engineer’s day; route-aware booking asks whether actually putting a job in that window protects the other 11 commitments around it.
• SLA-locked stops. Compliance visits, maintenance contracts and recurring programs with SLA windows: capacity-aware slots can chip away at those windows by accident. Route-aware slots protect them by design.
• High reschedule rate. Operations where customers reschedule often: capacity-aware portals create a steady stream of slots that look fine when picked but break the day when reconciled.
• Multi-skill mix. Where the right engineer for a job depends on skill: capacity-aware booking can offer a slot to an engineer who can’t actually do the work. Route-aware booking matches skill to slot before offering it.

The cost of unrouteable bookings shows up as missed windows, coordinator escalations, and the slow drift of customer trust.

At a glance: a 50-engineer drainage and waste operation

A drainage and waste contractor running same-day and next-day reactive call-outs across an urban region. Fifty engineers in the field, dispatched out of two depots. Roughly 70% of work comes in through the BigChange customer booking portal – customers pick a slot, the booking lands on the day’s board, BigChange’s route calculation slots it into an engineer’s day. JobWatch handles execution, vehicle tracking covers compliance, financials and BI run in BigChange.

The cost of capacity-only slots shows up downstream. A 13:00–15:00 slot offered to a customer at 09:00 looks fine in the booking portal but breaks the day when reconciled against the engineer’s actual position at 12:45 (still on a job from this morning, four jobs away from the customer). Failed-visit rate runs 8–10%. Coordinators absorb the reconciliation by phone. Customer trust drops on missed windows. Putting route-aware slot availability behind the same booking surface changes what comes back: only slots that the optimizer would accept against the current plan, given the customer’s location, the work type and the SLA. Failed-visit rate typically drops to 3–5%. Around 70% of customer-driven reschedules go through without coordinator involvement. The portal continues to live in BigChange.

How eLogii’s slot booking co-pilot works

eLogii’s slot booking endpoint takes a query (customer location, work type, required skill, SLA window) and returns only slots that fit the current optimized plan. The customer never sees eLogii. The booking surface keeps using BigChange’s portal, BigChange’s SMS link, or whichever channel is in use. What changes is the source of the slot list.

• Route-aware availability. Slots returned are slots the optimizer would accept – not slots that nominally fit a capacity bucket.
• Skill-matched. Only engineers who can do the work appear in the slot list. Skill mismatch never propagates to the customer.
• SLA-protected. Slots that would compromise existing SLA-locked commitments are filtered out.
• Customer-driven reschedule. Reschedule slots come from the same endpoint. The customer picks a slot that already fits; the route re-optimizes around the new commitment.
• Live driver GPS context. Real-time progress feeds the slot calculation, so late-day slots reflect what’s actually happening on the road, not what was planned at 08:00.

How the integration sits with BigChange

BigChange’s customer booking portal stays in place. The slot list it shows is sourced from eLogii’s slot booking endpoint over REST. the connector is custom-built.

1. Customer initiates booking. Customer hits BigChange’s booking portal as normal. The branded surface, the journey, the confirmation flow continue to live in BigChange.
2. Slot availability query. BigChange’s portal queries eLogii’s slot booking endpoint with the booking context (location, work type, required skill, SLA window).
3. Route-aware slot list returned. eLogii returns only slots that fit the current optimized plan. The portal renders them to the customer.
4. Booking confirmed. Customer picks a slot. The booking writes back to BigChange in the normal way. eLogii re-optimizes to absorb the new commitment. JobWatch picks up the assignment.

Most teams complete the connector build in 3 to 5 weeks. The same endpoint covers customer-driven reschedule from any surface BigChange uses.

Frequently asked questions

What is the difference between BigChange’s customer booking portal and a route-aware slot booking layer?

BigChange’s Standard plan includes an “Online customer booking portal” that offers customers slots based on capacity availability. The booking surface itself – the customer-facing journey, the brand wrapping, the confirmation flow – sits in BigChange. eLogii’s slot booking co-pilot is the route-aware availability calculation underneath: given the current optimized plan, which slots can actually be offered to a customer without breaking optimized routes. The customer never sees eLogii; the booking surface keeps using BigChange. What changes is which slots come back.

Why does route-aware availability matter?

Three reasons. First, slots offered to customers should be honorable: a slot that breaks the optimized plan ends in a missed window or a panic reassignment. Second, route-aware slot booking cuts failed visits materially – eLogii customers report around 35% reductions in failed visits where this is implemented. Third, around 70% of customer-driven reschedules can be handled without coordinator involvement when the customer can only pick slots that already fit the plan.

Does this replace BigChange’s customer booking portal?

No. The booking portal stays in BigChange. The customer journey, the branding, the confirmation, the data model continue to live there. What changes is the slot availability source. BigChange’s portal queries eLogii’s slot availability over REST, gets back only route-aware slots, presents them to the customer. The customer experience is unchanged in shape; the slots are different.

How does the integration sit?

Custom integration against BigChange’s RestAPI module and eLogii’s REST API. The booking portal in BigChange queries eLogii’s slot booking endpoint for available slots; eLogii returns only slots that fit the current optimized plan, given the customer’s location, the work type, the required skill and the SLA window. When the customer picks a slot, the booking is written back to BigChange in the normal way and eLogii re-optimizes to absorb the new commitment.

What about customer-driven rescheduling?

Same pattern. The customer initiates a reschedule through whichever surface BigChange is using (portal, SMS link, email confirmation). The available reschedule slots are sourced from eLogii’s route-aware availability. The customer picks a slot that already fits the optimized plan; the reschedule is written back to BigChange and the route re-optimizes around the new commitment. ~70% of reschedule requests handled without coordinator involvement in operations that implement this.