Reference

• Glossary
• Reporting an issue
• FAQ

Glossary

Terms used across the whole console. Dispatcher-specific vocabulary — driver states, Last-Option, TTB — is in the Dispatcher glossary.

Term	Meaning
Brand	A commercial identity within your company. Most screens work within one brand at a time, and data is separated by brand
Store	A physical location. Called a branch in some screens
Hub	An operational grouping of stores. Employees belong to a hub, and it determines which operation their work counts towards
Source	Where an order came from: web, app, kiosk, or an aggregator. Content and some reports are separated by source
Scope	What data an employee may see — brands, stores, sources. Set once per person and applied everywhere
Role	What an employee may do. A person can hold several; permissions combine
Permission	One specific ability, such as assigning a driver or exporting metrics. Roles are built from these
Exception	A grant or deny of one permission for one person, overriding their roles. A deny always wins
Business date	The trading day an order belongs to. Late-night orders belong to the previous business date, not the calendar date
Promised time	The delivery time the customer was given, and what lateness is measured against
Own fleet	Your own drivers, whether employed or contracted
Third-party carrier	An external delivery company you hand orders to. They choose the courier, not you
Redeemed	A promotion, voucher or credit the customer has already used. Bulk operations never touch redeemed records
Bulk change	Changing many records at once, via check → apply → track
Import	Loading records from a CSV. Never transactional: a partial failure leaves earlier rows applied
Backup	A retained snapshot of an export, which can be downloaded or restored
Alarm	Raised automatically when a store crosses a threshold. Lives in the Hub, and is archived once handled
Alert	Raised automatically about a driver, or returned by a threshold report in Reports
Incident	A record a person writes against one order, explaining what went wrong
Request ID	Identifies one dispatcher run. The single most useful thing to include when reporting a dispatcher problem

Three that are easy to confuse

Alarm, alert, incident. The first two are raised by the system and you respond to them; the third you write yourself and it stays on the order. See Branch alarms, Stores and driver alerts and Logging an incident.

Contracted driver versus third-party carrier. A contracted driver is part of your fleet and is assigned by name. A carrier is a company — you hand it the order and it picks the courier. See External employees.

Role versus scope. Roles decide actions, scope decides data. See Roles and scope: the two ideas.

Reporting an issue

How to report a console problem so it can be resolved without three rounds of questions.

For dispatcher-specific problems there is a fuller checklist in Reporting a dispatcher issue — the Request ID it asks for is what makes those traceable.

Check these three first

A large share of reports resolve here, without anyone else being involved:

Symptom	Likely cause
"I can't see the screen"	Your roles — What you can see, and why
"I see fewer rows than my colleague"	Your scope — How scope works in practice
"The total is missing an evening"	Business date, not calendar date — Filters, dates and favourites

None of these are faults, and all three are answered in a minute.

What to include

Detail	Why
Where you were	The area and screen, not just "the console"
What you did	The steps, in order
What you expected	Often the most useful line, and the one most often missing
What happened instead	Including the exact wording of any message
When	Date and approximate time
Who	Your identifier — it decides your roles and scope, so it determines what you should have seen
Brand	If your company has more than one
One-off or recurring?	A single occurrence and a pattern point to different causes

Identifying a specific order

An order needs store, ticket number and source together. A ticket number alone is not unique across stores, so a report with only a number cannot be traced.

If the dispatcher is involved, add the Request ID from the Scheduler — it points to one exact run.

Evidence that helps

• A screenshot of the specific screen showing the problem, with any message visible.
• For an order, its detail screen with timestamps — not a list view.
• If several things are affected, all the identifiers rather than "a few orders this morning".

What doesn't help

• "It's broken" or "it's not working today", without a screen, a time and an example.
• Screenshots of unrelated dashboards.
• A description of the fix you want instead of the behaviour you saw. Say what happened; the cause is often not where it appears.

Before reporting a permissions problem

Say which of the two it is — you can see the screen but not the data, or you can't see the screen at all. The first is scope, the second is a role. That one sentence often resolves it immediately.

FAQ

Cross-area questions. Each chapter has its own detail; this is the index for the ones that come up everywhere.

Access

Why can't I see an area other people can? Your roles decide which areas appear. See What you can see, and why.

Why do I see fewer rows than a colleague running the same report? Your scope is narrower, and you are both seeing the correct answer for yourselves. See How scope works in practice.

I have the role but still can't do one specific thing. Permissions are granular, and a deny exception overrides a role. Check Access by section, then Individual permission exceptions.

How do I get a password? Someone with employee management rights sets it. There is no self-service reset — see Signing in.

Data and numbers

Two reports disagree by about one evening's trade. Business date is not calendar date; late-night orders belong to the previous business date. See Filters, dates and favourites.

Reports and Metrics disagree about an order. They read different stores of data. An order present in Reports but absent from Metrics generated no log events — it is not lost. See Reports and Metrics: which to use.

A bulk change affected fewer records than the check said. Records redeemed between the check and the apply are excluded, as are any already redeemed. See How bulk changes work.

Orders

Why did an order change driver by itself? A driver with better priority became available. See When an order changes driver.

Why is an order still unassigned? Usually capacity, a zone that allows no available driver type, or incomplete address data. See the Dispatcher FAQ.

I unassigned an order but the carrier still came. Unassigning does not cancel with the carrier. Cancelling does, atomically. See Assigning and unassigning a driver.

An order I assigned by hand never got reassigned. Manual assignments are permanently locked out of automatic reassignment. That is intended. See The order board.

Content and promotions

I changed a banner and nothing changed. Almost always the wrong source selected — content is stored per source, and per language for banners and documents. See Resources and sources.

A customer's promo code doesn't work. Check dates and valid times, whether that coupon is already redeemed, and whether the offer is live for that store. See Promotional codes.

A carrier looks available but shows as full. Carrier capacity is one shared pool per store per company, not per courier. See External carriers.

Imports and exports

An import failed halfway. Can I just re-run it? Not safely. Imports are not transactional, so earlier rows are already applied and re-running may apply them twice. Find where it stopped first — see Importing from a CSV.

Can I undo an import? Only for records nobody has redeemed, via a bulk delete. Anything already used stays.

Why is exporting a separate permission? Because an exported file is no longer scope-filtered. See Exporting data.

Still stuck

Reporting an issue lists what to include so it can be resolved first time.