← All work

CrewDispatchr

Client delivery

A staffing and dispatch platform for field operations — scheduling, crew assignment and shift changes in one system instead of a phone tree.

  • Schedules and dispatches crews against jobs and availability
  • Handles shift swaps and no-shows as first-class events, not exceptions
  • Gives the office a live view of who is where
  • Captures the informal coordination that used to live in phone calls
  • Feeds downstream payroll and billing with clean data
CrewDispatchrToday · Dispatch board
23/24jobs crewed
JobCrewStatus
Riverside · Site prep4 assigned · 07:00On site
Harbour Rd · Finishing3 assigned · 08:30On site
Depot · Load out2 assigned · 06:00Complete
Kings Park · InspectionUnassignedNeeds crew
Representative view, drawn from the delivered system's documented behaviour.
Domain
Field operations and workforce dispatch
Hard part
Real-world churn — the schedule changes all day
Integrations
Payroll and billing handoff
Constraint
Built and run alongside fractional technical leadership
Built with
Staffing SaaS platform · Scheduling and dispatch services
Specified first
Dispatch process map · Roadmap and sequencing · Build-versus-buy assessment · Vendor specification
Engagement
Fractional technical leadership · Staffing and field-services operator

Why it holds up

The engagement

This one did not arrive as a project with a scope to define. It arrived as an operator who needed technical decisions made and owned — what to build, what to buy, what to stop doing — alongside the delivery itself. The engagement model was fractional technical and operational leadership, not a fixed-scope build.

Where the analysis went

The discipline is the same at roadmap altitude; the artifacts differ.

Dispatch process map. Scheduling and dispatch were documented as they actually ran, including the phone calls and the shift-swap messages that no system knew about. Those informal paths are where the requirements live.

Build-versus-buy assessment. For each capability on the roadmap: is this genuinely differentiating, or is it a solved problem we are about to rebuild badly? Most of the answer was buy, which is a cheaper answer to reach during analysis than after a sprint.

Vendor specification. Where the answer was buy, the requirement still had to be written down — a vendor cannot be evaluated against a feeling.

Outcome

Worth stating plainly: this is the one engagement of the three that was client delivery rather than an own product, and it is the one where the analysis was least like a formal specification. Both facts are labelled rather than smoothed over.

Building something like this?

30 minutes, free. Bring a problem or bring a spec.

Book a discovery call