How to use Dispatch /

Before you begin

Explore the overview and insight screens with example records, or open the private dashboard to see metrics calculated from your saved workflow records.

Create an account in Dispatch and work in its own private workspace. Accounts and records from another Lumia product are separate. 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.

Follow the workflow below to understand the application. Contact Lumia for a guided walkthrough; account access is private. An exported file reflects the record at the time of export.

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.

Operating the product

Start with the public interface preview to explore overview and insights using example records. Open /dashboard for account-scoped metrics calculated from your saved records, or /desk for the underlying workflow.

Treat job identifiers as durable business references. Reusing an identifier for different work makes duplicate protection ambiguous; changing the identifier merely to bypass a conflict could create duplicate service visits.

When a version or commit conflict appears, reload the current plan and work orders before changing anything. Another operator may have committed valid work while the older screen was open. Review the resulting schedule, then make a new decision against the latest version.

Retry an uncertain request with the same operation key and unchanged payload. If the command already succeeded, its original result is returned. A changed decision should use a new key after inspecting the current state.

Investigate unassigned explanations in the input: add a missing directed route, correct a skill or stock assumption, or move the service window. Do not interpret a missing assignment as a notification sent to the customer or technician.

Keep local work-order evidence separate from external operating systems. Before relying on Dispatch for a real service day, define who updates the source roster, who approves changes and how a verified backup can be restored.