The Driver App

What this is

What the driver sees

• Log in. A driver signs in with their StatVault driver login and password.
• Mission screen. The driver's home screen and today's manifest, drawn as one numbered list down a rail. Each number is a visit: the time on the left (READY, DUE or PREF, and the clock), the place and address, and a line for every job there. Neighbours at one door share a visit with a heading such as DROP ALL · 3; a later return to a building already on the list is its own visit, headed BACK HERE. Departments of one building are titled by the building. The visit at the building they are standing at is tinted blue and headed HERE SINCE 3:49. Each job line starts with a pill - PICK UP or DROP, blue on route stops - and carries a tag only when it is true: LATE, UNSENT, HELD, SCANNED, DO NEXT, PHOTO WANTED, 1st (first trip there). A drop appears only once its order is aboard. While any order is unconfirmed a red NEW ORDERS · TAP TO CONFIRM strip sits above the list; tapping it opens the first order's confirm popup and jumps the list to the top. Also above the list: the 3 ABOARD chip (tap it: what is aboard, by drop place, with Start drop) and the 4 done · last at Phelps 2:48 bar. Any other day wears a NOT TODAY strip that returns to today. Other tabs: Map, Sensors, Chat, Me.
• The order of the day. The list's order: unconfirmed orders, then what is in the car, then the order dispatch pinned DO NEXT, then the rest by time with route stops as fixed points. A sequence dragged on the board decides which order sits in which order slot and nothing else; route stops never move, and a job is never moved to join a visit.
• Confirming an order. An unconfirmed order is a pale amber line with a CONFIRM button; tapping the button or the line asks the driver to accept. It only acknowledges the order - it is not a pickup.
• Picking up and delivering from the list. Swiping a job line right starts the next step: a piece count for a pickup, the name of who received it for a drop, on a sheet above the keyboard. The order screen's checks run first - dispatcher prompts, a required photo, the distance warning, and "This stop isn't ready until 4:00 PM. Pick up anyway?". Route stops open their own screen instead.
• The pickup and drop checklist. The order screen has Start pickup and Start drop, and a drop visit's DROP ALL · 3 heading opens one drop for every order aboard for that building. Steps: Arrive (GPS; being far away warns, never blocks), Prove you are at the box (the scan), Count pieces (pickup: type the number or nudge it) or Hand off (drop: tick the orders the place takes and who received them, a person not a desk), Photo and Signature only when the order requires them, and last Pick up · 12 pc or Deliver · 4 orders. That button is a step in the list, never a bar at the bottom, and stays locked, saying "Still needed: piece count, photo", until every required step is done; the header counts steps, 2 of 5. One scan, hand-off and signature cover the whole drop. It queues offline; the list swipe and the without the checklist links keep working. A finished drop returns to the day's list.
• The drive. After the pickup the same screen becomes the drive: when it was picked up and with what proof, then the drop - its name, how far from the last GPS fix, the due time, and how many orders and pieces aboard it covers - with Navigate. It is not a step: when GPS puts the driver at that place the drop checklist opens by itself, and Start the drop now opens it without a fix.
• The scan: NFC, barcode or photo. At a box, the proof step offers Tap the NFC tag, Scan the barcode and Photo of the box instead (Photo of the drop instead on a delivery); any one proves the driver is there, none is required, and a photo taken here also counts for a required photo. Nothing to scan here, or it will not read skips it after a reason is picked: the order still goes through, and the reason reaches dispatch: in the delivery notes as "No scan: ...", or after a pickup in the order's custody timeline. Scan the barcode takes the number typed from under the bars until the camera scanner arrives, marked TYPED: the driver's word, not a scan. A tag tap while the checklist is open counts for the step. On the custody rail a scan or photo is a filled dot, a typed number a hollow one, a skip an amber dashed No scan.
• Words on a line. PICK UP is not yet picked up, DROP is aboard, UNCONFIRMED is the amber line. HELD is a tap the server refused - the same word on the line, in the queue sheet and on the end-of-day screen; UNSENT is a tap waiting for signal. The order screen's header chip says UNCONFIRMED, CONFIRMED, ABOARD, DELIVERED or CANCELLED.
• The order screen. Opening an order: the number, type and pieces with the status chip; a real map strip (OpenStreetMap) with the road route to the next stop and its miles, never a straight line (Navigate opens the maps app); then the Next card: the stop's pill and name, READY / DUE / PIECES (DUE / PICKED UP / PIECES once aboard), one sentence saying what proof the stop needs, with its reason, Start pickup or Start drop into the checklist, and Navigate / Call site / Dispatch. Under those, quieter links: Pick up without the checklist or Deliver without the checklist (the older two-step flow; Sign & deliver when a signature is required), Proof photo at any point, and Type a barcode before the pickup. Then Both stops, the Order facts (pieces, weight and parcel have Edit; for 12 minutes after a delivery, editing the count reopens the order), the Custody rail and Message dispatch. An unconfirmed order shows Confirm task first; a delivered one shows when and to whom.
• The custody rail. The bottom of the order screen is the order's chain, oldest first. A filled dot is something the system saw: a tag or barcode on the box, a photo, a signature (server-held taps survive a restart). A hollow dot is something a person said: ordered, assigned, confirmed, a pickup or delivery tap with nothing attached. An amber dashed dot is a scan that should be there and is not; a grey dashed dot is the next step, reading the checklist to come. Photos and the signature sit under the step they prove; tap one to see it. After the drop a line sums it up ("A barcode at the box, a photo at the pickup and a signature at the drop", or that the order moved on the driver's word alone).
• Required photo or signature. When an order requires proof (a proof rule for its type, account, site, door or box, or the order's own Require from the driver switches), the app holds the driver at that step until it is captured: a pickup photo when they start the pickup (checklist, order screen, list swipe or NFC tap), a delivery photo or signature when they start the delivery. The way out for a broken camera or a recipient who will not sign is to message dispatch, who can always complete the order from the board; anyone signed in to the app, a dispatcher included, is held the same way. The order screen's Next card says it in one sentence, with the reason when dispatch or a rule gave one, and its Order section has a Proof line. Photos and signatures are saved on the phone first and sent later; proof already received is not asked for twice.
• NFC box scans. Many sites have an NFC box (a lockbox at that location - never call it a SmartBox, that's our own IoT device); sites without one are completed by hand. On Android the app listens for a tag tap while it is open and matches it to the right order or route stop. On iPhone the driver starts each read: a Scan NFC box button on the order screen, the route-stop screen and the mission header (and Tap the NFC tag in a checklist) brings up iOS's "Ready to Scan" sheet, then behaves like an Android tap. If one box could belong to more than one building or order, the driver picks from a list rather than the app guessing. A tap marks that side of the order scanned and sends the at-origin (or at-destination) time to CXT, stamped with when the tag was read.
• Route stops (recurring routes). A route stop's screen shows the stop's notes, an access-notes drawer for the site, a place for the driver to add their own note, a Photos section (camera only, no library picker), and a Mark Done button. Completed stops show a completed time and piece count. A pickup stop that needs a photo (such as the end-of-day box-clear photo) says Photo required before Mark Done and why, and asks for it first; Can't take one keeps the reason as the driver's note and completes, and the box counts as not cleared.
• Both stops on the order screen. Each stop is a row: the PICK UP or DROP pill, the place and address with its collection point, one line of access facts from the site page (floor, suite, department, specimens, door code, lunch, lockout, key required, the site's notes), what the site wrote in a FROM THE SITE block, dispatch's comments on that stop, the dispatcher's prompt with Got it, the place photos and Improve this place. When the site page has opening hours they sit behind a collapsed Hours ▸ line; a tap opens them.
• "Needs photo / info" requests. When a dispatcher flags an access point as needing a photo or information (set on the site page, see Site Intelligence), the driver sees it three ways: a small camera marker next to that stop's name in their order list, a Dispatch needs chip on the order or route-stop screen that opens Improve this place (Improve this location on a route stop) with the request pinned at the top, and, if the dispatcher ticked the popup option, a popup at the pickup or delivery moment with Add photo / info (which opens the order screen ready to contribute) or Continue (proceeds without it; the popup guarantees the driver saw the ask). It is an ordinary Box Bux contribution, no special reward: it queues offline, is reviewed on the Box Bux page, and approving it clears the request.
• Loud alerts. New orders, their reminders and a dispatcher's Ring phone (for a lost phone) play at alarm volume, through silent mode. Tapping the ring stops it; a confirmed order's alerts clear themselves.
• Chat and pins. The Chat tab is ordinary messaging with dispatch. Separately, dispatchers can send a driver a "pin" - a location with a Navigate button. A pin first arrives as an ordinary chat bubble. Only a pin sent with Require acknowledgment escalates: after the first reminder it takes over the screen and comes back every time the app is opened until the driver answers. See Chat, acks and the driver app.
• What Zippy can answer for a driver. Only about that driver's own work: their orders and today's route stops, drive times, time-off requests, what's on file for one of their stops ("I can't find the box": what the stop screen shows, photos included, nothing more), and whether a scan reached the server ("did my scan go through?" - proof recorded, tap received but not matched yet, or nothing received, which usually means it is still on the phone waiting for signal). If nothing is on file, Zippy says so and points to dispatch instead of guessing.
• Asking Zippy. A driver's questions are kept as that day's conversation (your organisation's calendar day).
• Offline behavior. With no signal, status changes, scans, notes, photos and e-signatures queue on the phone instead of failing and keep retrying. The driver sees their sync debt as a chip and a queue view. Photos and signatures are written to the phone's storage before anything is sent, so a dead zone, an app kill or a logout no longer loses them; tell a driver to carry on. An unsent photo counts against their end-of-day sync gate like any custody evidence. If a capture cannot be stored at all the app says so and asks for a retake; only then is evidence lost. BoxBux contributions and the check-in selfie queue the same way; a resend is never filed twice and a stop never completed twice. A pending Message acknowledgment in the queue is a chat ack, not custody.
• Held actions. Not everything that queues can be sent. If the server refuses a tap - most often because the order moved on before the tap arrived - the queue entry becomes HELD and is not retried. It still counts against the driver's sync debt, and the queue view's Tell dispatch button posts a line into the dispatch chat. Held entries clear themselves once the server is seen to hold what the tap recorded; one that will not clear means the server never got that action - a real gap, check the order.
• GPS. The app reports the driver's location in the background while it is running, so their position keeps updating on the dispatcher map between taps. On Android that is a native service that survives the app being swiped away. On iPhone it is an iOS background-location session: the driver must answer Allow While Using App and then, when iOS asks again, Change to Always; until they do, the position only updates while the app is open. A blue pill at the top of the iPhone screen in the background is iOS showing tracking is on. An iPhone driver who answered Keep Only While Using sees a red Location is not set to Always banner on the mission board; tapping it opens Settings, the only place iOS lets them change it. Dispatch sees the same condition in the device-health line.
• Cooler thermometers. While the app is open on screen it listens for the Bluetooth thermometers in the driver's cooler (RuuviTag and Govee) and relays their readings - a short listen every two minutes and at each confirm, pickup, delivery, box scan or completed stop, when they stand at the cooler. A locked phone reports nothing; readings show in the map's Sensors panel (Dispatcher Map).
• End of day. Logging out is gated: if the driver has custody-relevant actions (status updates, route stop completions) that haven't reached the server yet, the log-out screen keeps forcing a sync attempt and shows an "N of M synced" count. Log Out stays disabled until everything is through, with a narrow override. The same screen shows Boxes cleared today · 3 of 4: the specimen boxes whose last pickup of the day was this driver's, naming any NO PHOTO or PICKUP OPEN.
• Settlements. A Settlements screen lists past pay settlements (Paid or Approved), each expandable into its order lines and pay amounts.

What dispatchers see from it

• Stop-detail modal. Opening a route stop's detail shows the driver's note and any photos they added, right alongside the stop's other info.
• Editing an order's pay from the app. A dispatcher who changes pay in the app's order editor goes through the same pay path as /verify and Order Detail: it lands on the live pay row, is recorded in the order's history and is sent to CXT. If the pay cannot be applied (no driver on the order, two live pay lines for one driver, a driver who is not on the order) the whole edit is refused and the app shows "Save failed" with nothing changed.
• Bulk assign from the app. As on the board: an order taken from another driver leaves their phone, a post-pickup handoff joins the custody chain, and one already theirs is untouched.
• Dispatch Board proof indicators. Orders with a photo or signature attached show a small camera/signature marker so you can tell at a glance that proof came in.
• Event Log. Every photo a driver adds, to an order or a route stop, and every e-signature, is also a line in the map's Events tab the moment the server receives it (see Event Log).
• Ops Manifest and the route popout. A driver's live manifest page mirrors what's on their phone - same statuses, same route stops. Stops the driver noted or photographed carry a ✎ / 📷 marker in the stop list; click the row for the note and photos themselves.
• Driver names on the app's map. Captains and dispatchers who see other drivers on the app's Map tab get each marker as the driver's number plus first name only ("621 Alex"), the same first-name convention used across the suite. Nicknames set in the driver profile are not used on the map.
• The map's Events feed. A note or photo appears in the /map Events panel the moment the driver saves it, naming the driver and the stop, with the stop name clickable straight through to the detail. See Dispatcher Map.
• /routes. The stop list shows the driver's note inline under the stop, with a photo count beside it.
• Customer account list. A dispatcher-mode driver picking a customer for an order sees the same shared account roster as Customers, New Order, and /search.

Common driver questions and what to tell them

1. "I confirmed the order but it still says NEEDS CONFIRM." Ask them to check their connection - confirms queue offline and sync once they're back online.
2. "The app won't read the NFC box." Have them try again holding the phone flat against the box. If it still won't read: Scan the barcode where the site has one, or Nothing to scan here, or it will not read with a reason, which reaches dispatch. The order still moves normally: the scan is evidence, not a gate.
3. "I scanned a box and it asked me to pick a building." That's expected when one NFC box is shared by more than one building or order at a site - they should pick the right one from the list.
4. "My photo/signature didn't attach." It is queued now, so the first question is whether it has simply not sent yet - their sync chip will show it as outstanding. It will go on its own once they have signal, including a photo for a stop from an earlier day. It only needs recapturing if the app told them at the time that it could not be stored.
5. "I can't log out." That's the end-of-day sync gate - they have unsynced custody actions. Tell them to stay on Wi-Fi/signal a minute and let it finish syncing before trying again.
6. "Why does this order say Delivered when I haven't touched it?" Someone (a dispatcher or ESV) may have marked it on their behalf - check the order's history/audit trail rather than assuming the driver's phone is wrong.
7. "A message popped up and won't go away." That's a pin from dispatch requiring an answer - it will keep reappearing until they respond to it.
8. "Where do I see my pay?" The Settlements screen in the app, under their profile/tabs area.
9. "I lost my phone." Ring it: Ring phone (lost phone)… on their row in the map's Drivers roster.
10. A driver posts "Held action on #100200: ..." into the chat. That is the Tell dispatch button on a HELD queue entry, not a live failure - the tap it names may be days old, and the driver is asking you to check the order. Look the order up: if it already reached that state, nothing is owed and the entry clears itself. If it did not, that action never landed and needs fixing on the order. The same line can appear more than once: each tap of the button posts again.

Things that confuse people

• "NFC box" always means the lockbox at the customer site (CXT's term), never our SmartBox device - the wording matters if a driver or customer says "the box" and you need to know which one.
• A large system text size (iPhone Settings > Display > Text Size, or Android font size) makes labels grow a little, but rows keep their shape. If a driver still complains about layout, check the text-size value in the phone's device-health line first.
• Every time in the app is shown in the organization's time zone, not the phone's. The zone comes down with the login, so a driver travelling out of zone still sees the same clock dispatch sees, with the org's suffix (ET, CT, ...).

Related

• Manifest and Ops Manifest
• Custody
• Coverage Calendar
• How Messages Reach Drivers (Chat, Acks, Pins, Nudges)