Challenge

Challenge: Dispatch Reliability and Reconciliation

How might we make BetterFleet Dispatch trustworthy enough to become the operational source of truth for day-of-operations EV dispatch, so depot teams can assign, reconcile, and adjust service confidently without falling back to spreadsheets, paper sheets, yard walks, and disconnected systems?

Motivation

• The current dispatch product already covers schedule import, day setup, block generation, advisory vehicle recommendation, and manual allocation, but the source documents show that operators still do not trust it enough to depend on it operationally.
• Dispatchers are currently absorbing the risk of uncertain SoC, incomplete yard visibility, schedule drift, and last-minute changes through workarounds rather than through the product.
• Several of the most immediate operator complaints are not about the big long-range roadmap; they are about the current product being painful to test, hard to trust, and missing essential reconciliation and exception-handling workflows.
• Until BetterFleet Dispatch is credible for real day-of-operations use, larger goals such as charge-aware automation, deeper integrations, and system-led assignment will remain hard to adopt even if they are technically possible.
• The interview and strategy material also shows that the dispatch opportunity is commercially important because EV utilisation, diesel substitution, service reliability, and operator confidence are all tied to how well dispatch works in practice.

Context

• The two upstream documents describe the same problem from different angles:
• a current-state and future-direction review that explains what Dispatch has today, what is broken, and where the broader roadmap points next;
• an interview and venture-design synthesis that explains why dispatchers, yard coordinators, and operations leaders still work around the product.
• BetterFleet Dispatch sits inside BetterFleet Manage and currently spans schedule ingestion, block generation, energy estimation, viability assessment, and manual operator assignment.
• The current implementation is still advisory-first. Operators can force an allocation even when the system warns them, which means trust in the warnings and clarity of the UI matter more than hard enforcement in the near term.
• The current product has a broader future ambition around charge-aware forecasting, recommendation-led assignment, external schedule ingestion, and deeper system integration, but the immediate challenge is that present-day users still lack a reliable operational workflow.
• The narrower active artifact set for this challenge focuses on restoring operator trust and adding essential reconciliation/manual-exception capability before larger automation or integration steps.

Domain Modelling

• Domain: day-of-operations EV dispatch inside BetterFleet Manage.
• Core entities:
• Schedule and its applicability period
• Dispatch Day
• Block of work
• Vehicle readiness and assignment recommendation
• Assignment plan
• Manual or ad-hoc operational change
• External operator dispatch sheet / assignment CSV
• The challenge sits at the seam between planning-time assignment, real-time exception handling, and operator confidence in the information shown by the system.

High-Level Use Cases / JTBD (Required)

• As a night dispatcher, I want to know which vehicles can truly cover the upcoming work so I do not rely on overly conservative rules or informal workarounds before morning pull-out.
• As a day dispatcher, I want one trustworthy place to understand block status, vehicle suitability, and assignment changes so I can react quickly without toggling across multiple systems.
• As a yard coordinator, I want dispatch information that reflects the physical reality of the yard closely enough to support movement and charging decisions while I am not at a desk.
• As an operations manager, I want the dispatch workflow to increase EV confidence and utilisation rather than reinforcing manual diesel-first fallback behaviour.
• As a depot team, I want to reconcile an external dispatch sheet against BetterFleet quickly and represent late manual changes explicitly so missing or ad-hoc work does not live outside the product.

Current State -> Desired State

Current State (Pain/Gain)	Desired Outcome	Success Measure
Pain: dispatchers still rely on spreadsheets, paper sheets, yard walks, and informal knowledge because the product is not trusted enough for live operational use	BetterFleet Dispatch becomes credible as the main working surface for assignment and review	Operators can complete core dispatch workflows without falling back to separate shadow tools for the same decision
Pain: started or completed work can still look actionable or unsafe because the current status and viability behaviour does not align cleanly to live operational reality	The system distinguishes future risk from live and completed outcomes clearly	Operators report fewer false alarms and can explain why a block still needs attention
Pain: future work visibility is inconsistent because time-window rules are split across layers	Dispatch has one clear future horizon contract	Users see the same future blocks consistently in the UI and underlying responses
Pain: schedule upload and schedule editing are brittle, and applicability cannot be corrected after upload	Operators can recover from schedule-period mistakes without starting over	Schedule setup becomes correctable in-product rather than by workaround or re-upload only
Pain: there is no efficient way to seed or reconcile assignments from an external dispatch sheet	Assignment reconciliation becomes a deliberate product workflow	Operators can export, review, import, preview, and apply dispatch assignment changes safely
Pain: late changes and replacement work cannot be represented cleanly because manual/ad-hoc blocks are not first-class	Manual and ad-hoc work can be added, updated, removed, and highlighted explicitly	Replacement or missing work is visible in Dispatch instead of living only outside the system
Gain to protect: operators retain override authority today, which is necessary while trust is still being earned	The product stays operator-led while becoming more reliable and informative	Manual control remains available, but the system becomes more useful and more frequently followed

Assumptions & Open Questions

• Key assumptions:
• BetterFleet Dispatch should remain operator-led in the near term rather than attempting immediate hard enforcement or full automation.
• Trustworthy status, clear visibility, and reconciliation workflow are prerequisites for broader automation adoption.
• The first reconciliation slice can reuse existing block-allocation persistence rather than needing a brand-new stored snapshot model.
• Manual and ad-hoc operational changes are unavoidable in real dispatch and should be treated as first-class product behaviour, not exceptional edge cases.
• Open questions:
• Which customers need which later integrations first, and in what commercial order?
• How far should mixed-fleet dispatch support go in the next stage versus later stages?
• What specific data-quality and trust signals most improve dispatcher confidence in SoC and readiness data?
• Which customer commitments are hard deadlines versus strategic aspirations in the source material?
• Validation plans (who/what/when):
• Validate the challenge with product and engineering against the current dispatch complaints and the two source documents.
• Validate with dispatch-domain stakeholders that trust, reconciliation, and manual/ad-hoc exception handling are the right near-term framing before broader automation.
• Validate later product slices against actual operator workflows, especially planning-time dispatch, day-of dispatch, and yard-floor coordination.

Constraints & Out of Scope

• Constraints:
• The solution has to work with imperfect data and varying customer system landscapes.
• Operators must retain manual override capability while trust is being rebuilt.
• Near-term work should improve the current BetterFleet Manage dispatch flow rather than depend on immediate availability of new third-party integrations.
• The challenge must stay grounded in day-of-operations value, not only long-range roadmap aspiration.
• Out of scope:
• Replacing CAD/AVL, scheduling, or yard-management systems outright in the near term.
• Finalising the full global integration strategy for every market and partner combination.
• Defining detailed technical design, schemas, or endpoint contracts in the challenge itself.
• Treating imported dispatch CSVs as durable historical records in the first reconciliation slice.

Evaluation

• User value:
• Dispatchers get a workflow they can trust more and fight less.
• Yard and operations users spend less time stitching together partial answers across multiple tools.
• Late changes, missing blocks, and external dispatch plans become manageable inside the product instead of outside it.
• Business value & strategic alignment:
• Higher operator confidence is a prerequisite for broader EV dispatch adoption and later automation.
• Better dispatch reliability supports EV utilisation, reduced diesel substitution, and stronger operational proof points for electrification.
• A trustworthy dispatch core strengthens BetterFleet's position as the operational decision layer rather than just another data surface.

Risks & Opportunities

• Risks:
• The initiative stays too broad and chases long-range automation before fixing the reasons operators distrust the product today.
• Reconciliation and manual/ad-hoc handling are treated as UI conveniences instead of product-critical operational workflows.
• Customer-specific integration ambitions distract from the immediate need to make the existing dispatch flow usable and testable.
• Opportunities:
• Re-establish BetterFleet Dispatch as a credible day-of-operations tool.
• Build a clear bridge from today's manual advisory workflow toward later charge-aware forecasting, automated ingestion, and recommendation-led dispatch.
• Create a reusable product pattern for reconciling external operator plans with BetterFleet-managed operational data.

Relationships

• Customer commitments:
• TTC-related dispatch expectations, Transdev integration asks, KCM charging-cost discussions, and Transdev VDS API requests are referenced upstream, but the exact commitment boundaries still need clarification.
• Related projects:
• Dispatch - Current State and Future Direction
• BetterFleet Dispatch venture/interview synthesis
• Dispatch reliability and reconciliation specification
• Upstream/downstream dependencies:
• Upstream discovery material comes from the current-state review and interview synthesis.
• This challenge feeds the active dispatch specification and the later story set for governed delivery.

Solution Ideas & Tradeoffs

• Idea A (Preferred): fix operator trust and workflow gaps first, then add reconciliation and manual/ad-hoc handling as the next operational layer.
• Best for restoring credibility and making later features testable in the real workflow.
• Idea B: prioritise deeper automation, external ingestion, and recommendation-led dispatch first.
• More ambitious strategically, but higher adoption risk if current trust and workflow friction remain unresolved.
• Idea C: focus only on exportable dispatch sheets and reporting outputs.
• Useful operationally, but does not solve the underlying problem of BetterFleet not being the live operational surface.
• Tradeoffs to compare:
• time-to-user-value versus roadmap ambition
• trust-building versus automation breadth
• operational safety versus workflow speed
• customer-specific integration pressure versus product-core usability
• Preferred direction:
• Idea A, because the source material shows that the biggest blocker is not only missing future capability; it is that current users still do not trust or comfortably operate the current product.

Release Sequencing

• Natural or value-based order:
• First restore trust in the current dispatch experience.
• Then make schedule setup and applicability recoverable.
• Then add reconciliation workflow for assignment import/export.
• Then add first-class manual/ad-hoc operational changes.
• Then revisit broader automation, ingestion, and deeper integrations from a stronger operational base.
• Smaller parts to solve first:
• Remove current workflow friction and false signals.
• Establish one clear visibility and status contract.
• Add safe reconciliation against external operator plans.
• Add explicit support for late and ad-hoc operational work.
• Potential slices/releases:
• Slice 1: trust and manual-testability fixes
• Slice 2: applicability and dispatch recovery improvements
• Slice 3: assignment CSV reconciliation
• Slice 4: manual/ad-hoc block lifecycle and highlighting
• Later: deeper automation, external ingestion, and integration-led expansion