Skip to main content

Trucking Dispatcher & Driver Workflow – Design Overview (Current + Next Steps)

1. Purpose​

This document describes the desired end-to-end trucking workflow for:

  • Dispatchers / operations (mostly web, some mobile)
  • Drivers (mobile)

It builds on the current features:

  • trucking-loads-and-legs
  • trucking-dispatch-scheduler
  • mobile-trucking-driver-experience

and focuses on polishing and aligning how dispatchers and drivers work together, starting with FC Trucking and Logistics Inc.

2. Roles & Responsibilities​

Dispatcher / Operations (Web)​

  • Owns:
    • Load creation and leg structure (stops, mileage, charges).
    • Assigning loads/legs to drivers and adjusting times.
    • Monitoring status and resolving issues.
  • Tools:
    • Job/Load page (source of truth for load details).
    • Scheduler (emerging dispatcher cockpit for assignments).

Driver (Mobile)​

  • Owns:
    • Executing assigned legs (pickup → delivery).
    • Providing status updates and basic proof (POD/BOL, notes).
  • Tools:
    • Mobile dashboard (today’s/ upcoming loads).
    • DriverLoads calendar/list.
    • Load details with documents and tasks.

3. Target Lifecycle (V1 Scope)​

3.1 Job/Load Stage Lifecycle (Web)​

Current trucking job stages (from job-stages.tsx):

  • New → Pending → En Route → Delivered → Invoiced

Usage:

  • New:
    • Load has been created (manually or via file import) but not yet published/visible for dispatch.
  • Pending:
    • Load is ready to be dispatched; legs and basic rates are set.
  • En Route:
    • Load is actively being worked (driver en route to pickup/delivery).
  • Delivered:
    • All legs are completed; load is ready for billing.
  • Invoiced:
    • Invoice has been generated/linked; load is financially closed.

V1 goal:

  • Make these stages clearly visible and actionable on the Job page for dispatchers.
  • Tie transitions more explicitly to:
    • Assignments (Pending → En Route).
    • Completion of all legs (En Route → Delivered).

3.2 Leg-Level Status Lifecycle (Driver + Dispatch)​

Current system supports leg-level statuses, but the driver UX is not yet formalized.

V1 target leg statuses (conceptual):

  • Scheduled
  • En Route
  • At Location (optional for future)
  • Completed

V1 behavior:

  • Dispatcher:
    • Moves a load to En Route once at least one leg is scheduled/assigned.
    • Can manually adjust leg statuses if needed (back-office corrections).
  • Driver:
    • Initially sees legs as Scheduled for the day.
    • Tapping an action (future enhancement) updates status:
      • Start → En Route
      • Mark Delivered → Completed

Short term:

  • Keep most status transitions driven from the web Job page.
  • Begin wiring mobile actions to a minimal leg status update API so drivers can participate where it makes sense.

4. Dispatcher Workflow (Phase 1)​

4.1 Today (FC Trucking and Logistics Inc.)​

  • Entry point:
    • Dispatcher/ops user starts on the Job/Load page, not a dedicated dispatcher cockpit.
  • Typical steps:
    1. Create load and legs (manual or file import).
    2. Set job stage to Pending.
    3. Assign driver(s) using job-level or leg-level controls.
    4. Optionally use scheduler to fine-tune timing and assignments.
    5. Manually set status to En Route / Delivered / Invoiced.

4.2 Near-term improvements​

  1. Clarify stage transitions on Job page
    • Make the buttons and stage labels match the intended lifecycle clearly:
      • From New → Pending (Publish).
      • From Pending → En Route (Start Job).
      • From En Route → Delivered (Mark Delivered).
  2. Connect stages to leg readiness
    • When moving to En Route, ensure:
      • At least one leg is assigned to a driver.
      • Appointment times or schedule entries exist.
  3. Lightweight dispatcher “view” using existing scheduler
    • For FC Trucking:
      • Provide a simple, documented pattern:
        • “Open scheduler from Job page to assign and adjust legs.”
      • Focus on a small set of views (Timeline + List) for now.

5. Driver Workflow (Phase 1)​

5.1 Today (FC Trucking and Logistics Inc.)​

  • Drivers:
    • See “Today’s Loads” and “Upcoming Loads” on the mobile dashboard.
    • Can open DriverLoads to see legs per day.
    • Can open load details and documents.
  • Limitations:
    • Status updates are not consistently driven from mobile; dispatch/back office update statuses on the web.
    • HOS, route guidance, and checklists are not present yet.

5.2 Near-term improvements​

  1. Highlight the next leg
    • On the dashboard and/or DriverLoads:
      • Visually emphasize the driver’s next scheduled leg (by time) for the current day.
  2. Introduce simple driver actions (behind feature flag)
    • Add minimal actions to the Load/Leg detail screen, e.g.:
      • “Mark En Route”
      • “Mark Delivered”
    • Wire these to leg/job status updates in the API, but keep:
      • Backward compatibility.
      • Tenant-configurable behavior (only enable for FC when ready).
  3. Feedback to dispatcher
    • Ensure driver status changes:
      • Reflect on the Job page and scheduler views (even if only on refresh at first).

6. Role of Dispatcher (Conceptual)​

While the exact dispatcher role is still evolving, the intended responsibilities are:

  • Own the status lifecycle for loads:
    • Ensure no load moves from New to En Route without appropriate assignment.
  • Manage driver workload:
    • Use scheduler and dashboards to avoid overload and conflicts.
  • Be the bridge between:
    • External systems/communications (broker emails, ELD data, etc.).
    • Internal job/load representation (AttuneLogic Jobs/Legs).

Future enhancements (beyond Phase 1):

  • Build a dedicated dispatcher cockpit:
    • Integrate unassigned queue, scheduler, and job lists into a single view.
    • Add HOS summaries and alerts for drivers.

7. Implementation Notes & Guardrails​

  • Start with non-breaking enhancements:
    • Clarify labels and actions on existing Job and scheduler UIs.
    • Add optional driver actions as feature-flagged behavior.
  • Keep FC Trucking workflows in mind:
    • Validate changes with their existing patterns before generalizing.
  • Document changes as they land:
    • Update the Feature Status docs (trucking-loads-and-legs, trucking-dispatch-scheduler, mobile-trucking-driver-experience) whenever behavior changes in production.