Dispatch /
A workable day, before the first call.
Build and review technician schedules against skills, parts, time windows and travel, then issue work orders.
- Practice
- AI & automation
- Built by
- Lumia Digital
- Application
- Independent source & workspace
- Current release
- Local / September 2026
A focused view of the working day.
A field-service dashboard shows the latest saved plan, assignment coverage, unresolved jobs and recorded completions. The planning board retains the detailed schedule.
D3 schedule timelineSee how Dispatch thinks.
Every Lumia system earns its own operating language. This view shows the decision surface, evidence trail and human checkpoint built around this workflow.
Interface study / controlled local workspace / human review remains in the loop.
The problem worth solving.
A field-service schedule can look complete while still being impossible to execute. A technician may have the right opening in the diary but lack a required skill, a replacement part or enough travel time from the previous stop. When dispatchers prepare separate plans, each plan can appear feasible even though they compete for the same technician. Dispatch brings those constraints into one local planning and approval workflow.
The product is designed around an operator who already knows the jobs, technicians and travel assumptions. They enter that information, inspect a proposed allocation, resolve unassigned work and approve a specific version before creating local work orders. The intended benefit is a clearer explanation of what can be scheduled and what still needs a decision. An explicit unassigned job is more useful than a confident assignment that silently ignores a missing travel route.
This is an independently built application evaluated with synthetic local schedules. Its evidence concerns feasible assignments, approval boundaries and conflict handling. It does not establish shorter real-world routes, higher technician utilisation or customer outcomes. Those would require an operational pilot with agreed baselines and reliable travel data.
Designed for: Small repair, maintenance and installation teams with a dispatcher, a known technician roster and enough job detail to state skills, parts, time windows and travel assumptions. It is most useful where a person needs to review the plan before work is issued.
From input to a useful result.
Describe the service day
Choose the planning date and timezone. Give every job a stable identifier, location, duration, service window, priority and required skills. Enter the required part quantities as whole units. Stable identifiers matter because a job already committed in another plan must not be scheduled again under the same identity.
Make operating assumptions explicit
Add technicians with shifts, skills, starting locations and carried parts. Supply directed travel times for the routes the plan needs. Travel from A to B is not automatically assumed to equal travel from B to A. Missing routes remain visible in the planning outcome instead of becoming zero-minute journeys.
Review assignments and exceptions
Inspect proposed stops and unassigned-job reasons. Use locked assignments only when their technician, duration and window are already valid. Resolve shortages, missing travel information or incompatible skills in the input, then review the resulting plan. The scheduler produces a feasible proposal; it does not claim a globally optimal route.
Approve, commit and close work
Approve the current version and content digest, then commit it to local work orders. Approval alone does not create work orders. The commit rechecks existing work for duplicate jobs, technician overlaps and travel gaps. Record a completion note when a scheduled work order is finished; a repeated successful command must not create another order.
What the software actually did.
These results come from internal workflow testing of the local product. The records are controlled test inputs; customer deployments and commercial impact have not been measured.
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.
Make the boundary clear.
- 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.
Questions before you start.
Does Dispatch find the shortest possible route?
It constructs a proposal using a constraint-checked insertion heuristic and reports that global optimality is not established. The useful question is whether each assignment can meet the entered windows, skills, parts and travel requirements. Route quality should be evaluated separately with representative operating data.
Why can a job remain unassigned?
A required skill, part, travel route or usable time window may be missing. The returned reason helps an operator address that specific constraint. Assigning every job would not be a success if the result required a technician to perform impossible travel or use unavailable parts.
Can two approved plans use the same technician?
They can use separate feasible periods. At commit, the server also checks already committed work, including adjacent travel requirements. In the concurrent overlap test, only one competing plan committed. Approval is permission to attempt the current plan, not a reservation that bypasses later conflict checks.
Does committing a plan notify technicians or create calendar events?
The tested target creates local work orders. An external calendar target returns a provider-not-configured error. Technician notifications and external calendar delivery have not been verified and should not be presented as completed actions.