Dispatcher Journey

Role: Assigns and manages orders to operators, coordinates fleet
Org: Kaya Sync (platform-wide) OR Client organisation (own org only)
Scope:

• Kaya Sync Dispatcher, sees all organisations, all orders, all operators
• Client Dispatcher, restricted to their own organisation's orders and fleet

---

Preconditions

• Account created by System Admin with Dispatcher role
• Scope configured (platform-wide or org-restricted)

---

1. Order Queue Management

Step 1.1: Monitor Incoming Orders

• Dispatcher views all orders in ReadyForDispatch state
• Filters available by: corridor, origin, destination cluster, container count, priority
• Orders only appear in queue after all containers have passed origin scan

Step 1.2: Review Order Details

For each order, Dispatcher can see:

• Order ID, origin, destination cluster
• Container count and packaging types
• Designee phone numbers (masked for privacy)
• Integrity assessment results from origin scan
• Time in queue (SLA visibility)

Step 1.3: Prioritise Orders

• Dispatcher can flag high-priority orders (e.g. perishables, SLA-bound)
• Urgent orders surfaced at the top of the queue

---

2. Operator Assignment

Step 2.1: View Available Operators

Dispatcher sees operators who are:

• Status ACTIVE
• Have a valid SOD attestation (Valid state)
• Are in or near the origin corridor
• Have sufficient remaining capacity (from telemetry heartbeat)

Step 2.2: Assign Order to Operator

• Dispatcher selects operator and assigns the order
• System validates:
  • Operator has valid attestation (BR-09)
  • Operator's capacity is sufficient for the container load
  • Operator is within service area
• Container state: OriginVerified → InCustody
• Operator notified via SMS/Push

Step 2.3: Multi-Operator Dispatch (split loads)

• For large orders, Dispatcher may split containers across multiple operators
• Each operator assigned a subset of containers
• All subsets must complete origin → delivery for order to reach Completed

---

3. Fleet Tracking

Step 3.1: Real-Time Operator Telemetry

• Dispatcher views live map of active operators (sourced from telemetry heartbeats)
• Visible data per operator:
  • GPS position, heading, speed
  • Remaining capacity
  • Destination intent
  • Active container assignments
  • Current order state

Step 3.2: Monitor Order Progress

• Dispatcher tracks each order through its states:
  • ReadyForDispatch → InTransit → Delivered → Completed
• Alerts raised for:
  • Orders stuck in InTransit beyond expected transit time
  • Integrity holds raised mid-journey
  • Operators deviating from expected corridor

Step 3.3: Identify and Escalate Issues

• Dispatcher escalates to Internal Ops Supervisor when:
  • Integrity hold is raised on an active order
  • Operator goes offline mid-delivery
  • Designee is unreachable (OTP delivery failure)
  • Unusual GPS deviation detected

---

4. Aggregation / Disaggregation Management

Step 4.1: Review Optimisation Recommendations

• System surfaces aggregation/disaggregation recommendations to Dispatcher
• Each recommendation includes:
  • Play type: AGGREGATION or DISAGGREGATION
  • Score: CarbonSaved − RiskPenalty − FrictionPenalty
  • Estimated carbon saving (kgCO₂e)
  • Recommended handoff point (name + GPS)
  • Counterparty operator ID

Step 4.2: Approve or Reject Play (Phase 1)

• In Phase 1, plays require human approval before execution
• Dispatcher reviews and approves or rejects
• Approved play creates a custody transfer between the two operators
• Automation of plays is enabled only after corridor confidence thresholds are met

Step 4.3: Monitor Play Execution

• Dispatcher monitors dual-scan completion for the play's handoff
• If receive scan fails or integrity hold is raised, Dispatcher escalates

---

5. Reporting

• Dispatcher can view:
  • Orders completed per day/corridor
  • Average transit times
  • Integrity hold rates
  • Operator utilisation
  • Aggregation play acceptance rates and carbon savings

---

Edge Cases

Scenario	Behaviour
No eligible operators in corridor	Order stays in ReadyForDispatch; Dispatcher manually seeks operator or escalates
Assigned operator's attestation expires mid-journey	Active order continues; operator cannot be assigned new loads until re-attested
Recommended play score is below threshold	Play not surfaced to Dispatcher (filtered by MIN_OPTIMISATION_SCORE policy)
Client Dispatcher tries to view another org's orders	Access denied, scope enforced at API level

---