What we tested in Dispatch /
The tests behind Dispatch: inputs, actions, observed results and the limits of that evidence.
Build and review technician schedules against skills, parts, time windows and travel, then issue work orders.
Internal local testing, using synthetic inputs and owned assets. The results below establish the observed software behavior in those scenarios. They do not establish customer ROI, uptime or external deployment readiness.
Nine local HTTP acceptance groups passed
The recorded Dispatch run passed nine groups covering authentication boundaries, deterministic route construction, input rejection, approvals, commit and completion replay, cross-plan conflicts and workspace isolation. Dispatch and ReturnPath together used 120 HTTP requests in their shared run; the report does not assign a separate request count to Dispatch.
Feasibility and failure paths were exercised
One fixture required a thirty-minute trip before a 09:30 first job and a fifteen-minute journey between later stops. The resulting schedule respected those inputs. Other fixtures supplied a missing travel route, insufficient parts, a duplicate job identifier or an invalid locked assignment and checked that the operation failed or retained the expected unassigned explanation.
Conflicting plans could not both commit
Two approved plans competing for an overlapping technician period were committed concurrently: one succeeded and one returned a conflict, leaving one work order. Separate cases rejected the same job on a different technician and a ten-minute cross-plan gap where the entered journey required thirty minutes. Stale approval data and premature commit created no work orders.
What the evidence does not establish
These are synthetic API-level correctness results, not a live dispatch trial, throughput benchmark or route-efficiency study. Exact retries, cross-workspace access attempts and an unavailable provider target were checked. This evidence set does not include Dispatch browser usability, real traffic information, technician notifications or a process-restart recovery drill.
What this evidence does not establish
The travel matrix is operator supplied. There is no verified live traffic, GPS tracking or automatic mapping integration in the tested workflow; incorrect travel assumptions can still produce an impractical day.
The heuristic does not establish global optimality. A feasible proposal may leave opportunities for a dispatcher to improve ordering, workload balance or business priorities.
Commit currently creates local work orders and accepts at most 45 assignments. External calendar creation is blocked until a provider is configured; no external delivery should be inferred from a local commit.
The acceptance run does not establish production capacity, backup restoration, team invitation or account-disable workflows. Those operating capabilities need their own implementation and verification before a wider rollout.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief