Reference Glossary, how to report a problem, and cross-area 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.