Reporting a dispatcher issue
If something looks wrong — an order assigned to the "wrong" driver, delayed, or stuck unassigned — the fastest way to get it resolved is to report it with the right information the first time.
Screenshots alone, especially of unrelated screens, rarely help. Specific, matched details do.
What to include
| Detail | Why it matters |
|---|---|
| Request ID | Identifies the exact dispatcher run involved. Shown in the execution summary on the plan's detail view in the Scheduler, and looks like req_1785152470621_6v3uobxk86e. This is the single most useful thing you can provide — more so than the store, because it points to one exact run |
| Order ID / ticket number | Without it, the affected order can't be traced |
| Store | Which store's run is affected |
| Date and approximate time | Narrows down which cycle to examine |
| What you expected | For example: "should have gone to an idle driver at the store", "should have stayed with the original driver" |
| What actually happened | For example: "stayed unassigned for 12 minutes", "was reassigned to a different driver", "went to a carrier instead of our own fleet" |
| One-off or recurring? | A single order and a pattern across many orders point to very different causes |
| Was it a Priority Customer (Platinum) order? | Helps rule the optional Platinum layer in or out |
| Any recent configuration changes | A zone, store or carrier setting changed shortly beforehand helps separate cause from coincidence |
What evidence actually helps
- A screenshot of the specific order's detail screen, showing timestamps and current assignment — not an unrelated dashboard or list view.
- If several orders are affected, list all the order IDs rather than describing them generally ("several orders around lunchtime").
- If you think a particular driver or carrier was skipped, name them, rather than saying "it didn't pick the right one".
What to avoid
- Reporting without the Request ID or the order ID. These are the two things nothing else can substitute for.
- General statements such as "the algorithm is broken" or "it's not working today", without a specific order, store and time.
- Attaching many unrelated screenshots instead of the one screen relevant to the order.
Before you report
Two behaviours are frequently mistaken for faults. Checking them first can save a round trip:
- A store where nothing has changed is skipped, not processed — see The assignment cycle, step by step.
- Editing a plan's Active field does not start or stop the cycle. Use the Activate and Pause actions — see Scheduling plans: how the automatic cycle works.
The clearer and more specific the report, the faster it can be matched against the actual run that produced the behaviour you're describing.