What's New

Restaurants running Reverb now hand the rider app its websocket connection at sign-in, so a new assignment, a reassignment or a cancelled order reaches the phone the moment it happens instead of on the next refresh. Nothing changes for restaurants without Reverb: the app keeps polling.

The address pencil the delivery portal has always had is now available in the rider app as a switch (Edit the delivery address, off unless the centre turns it on for a business). A rider can correct the delivery line of an unpaid order; it goes into the customer's address book exactly as on the web, and a paid, delivered or closed order refuses the change.

The four Rider App buttons on the POS Delivery grid — Hand-ins, Proofs, Runs and Riders Now — now sit under one Rider App dropdown on the toolbar, next to Bulk Payment and with the same permissions. Same modals, same actions, less toolbar.

Riders using the app can now see their own performance for today, this week or last week: deliveries, how many were on time against the same promise the order cards count down to, the typical door-to-door and handover-to-door times, failed attempts, kilometres ridden and hours on duty, with a day-by-day series, the busiest hour, a comparison with the previous period and the branch's own figures as an anonymous benchmark. The role label View performance (Rider App module) controls who sees it.

The owner app gets a riders leaderboard per branch from the same numbers, best on-time rate first.

With this, every feature of the Rider App programme is shipped on the ERP side.

Riders using the app can now share their live position while on duty. Each restaurant chooses where positions go under Business Settings → Firebase → Rider Tracking: its own Firebase Realtime Database (the phones write straight to your project and you pay only your own Firebase bill — most restaurants stay inside the free tier), or the ERP relay for restaurants without a project (phones report to the server once a minute). Paste the database URL and the client config, press Test to write and read a probe key, then Publish rules — the ERP signs riders in with the service account you already gave it for push and locks each rider to its own node.

On the POS Delivery grid a new Riders Now button shows every rider of the branch on duty, how long ago their last position came in, the orders out with them and a map link. The owner app gets the same list per branch.

At the door the app posts the measured trip (distance and time from handover, re-checked against the path) beside the area's expected distance — the rider-kms report is unchanged. And with the new business switch Rider app: customer tracking link, every order card carries a public tracking page the rider shares at handover: the order's status, the promise time, the rider's first name and, while it is on the way, the rider on the map.

Every order in the Rider App now shows when it is due and counts down to it. The promise comes from the delivery area's minutes when the area library has them, otherwise the branch's delivery promise (the same figure the owner app uses), otherwise 45 minutes. Late orders are flagged, the rider's list runs by due time, and the duty strip counts how many are late.

Riders can also take two or three orders as one run and deliver them in the sequence they choose. Each order still goes out through the normal handover — branch caps, prints and customer messages exactly as today — the run only keeps them together. It closes itself when the last order is delivered.

On the POS Delivery grid a new Rider Runs button (beside Delivery Proofs) shows the runs still on the road from the branch, in the rider's sequence, with each order's state.

Riders can now attach a photo at the door and verify a 4-digit code the customer receives on WhatsApp, SMS or e-mail (whichever the OTP & Recovery setup has switched on) before marking an order delivered.

Two new checkboxes under Business Settings — require a door photo and require the customer's code — make either one mandatory: the app then refuses "Delivered" until the proof is there. Leave them off and proofs stay optional.

On the POS Delivery grid a new Delivery Proofs button (beside Rider Hand-ins) lists today's proofs of the branch — which order, which rider, the photo, whether the code was verified. Photos are stored privately and open only for your own business.

With this, the Rider App's phase 2 is complete: cash in hand and hand-ins, earnings, could-not-deliver with reasons, problem reports, and proof of delivery.

A rider who cannot deliver an order now says so from the app, with a reason from a list (customer not answering, not at the address, wrong address, refused, and so on). The order comes back to the dispatcher on the POS delivery grid as ready, still assigned to the rider, with a line in the rider remarks saying why — nothing goes back to the kitchen. The dispatcher re-dispatches, reassigns, or voids it exactly as today, and every attempt is kept.

Riders can also report a problem from the road — a wrong address, an unreachable customer, the bike, a payment, their safety — with or without an order.

Both reach the owner app at once as two new alerts, Delivery failed (with an optional minimum amount) and Rider reported a problem, on by default and adjustable per branch like the other alerts.

Riders using the new Rider App can see the cash they are holding — every delivered order the register has not settled yet — and send a hand-in request when they bring it to the counter.

On the POS Delivery grid a new Rider Hand-ins button (next to Bulk Payment, same permissions) lists the open requests of the branch: who is bringing how much, for which orders. Confirm received records that the cash arrived; Settle opens the usual bulk payment on exactly those orders. Nothing changes in how money is booked — the request simply closes itself once every order in it is paid.

Riders can also read their earnings (the rider charge of each delivered area, and tips when the restaurant switches show_tips_to_rider on) — display only, nothing is accrued.

Riders check in and out from the app (the same duty columns and activity log the web portal uses), see their own orders for the business day — assigned, out, delivered, and the branch's unassigned ones when self-pick is enabled — with the customer's address masked until pickup when the restaurant says so.

Pick and Deliver run the exact POS transitions (branch caps, paid-bill refusal, KDS gate, customer notifications, auto prints, Blink status), so nothing happens in the app that could not happen on the web. Riders can add remarks the dispatcher sees on the grid and reprint the bill on the branch printer. Assignments, un-assignments and cancellations reach the rider instantly over the restaurant's realtime channel, with a push notification either way.

The foundations of the new Rider Delivery App are in. Riders sign in with their normal ERP account on /api/v1/rider-app/; the token is bound to one restaurant and one branch, so a rider moved off the position or off an active branch is locked out on the next request, not the next login.

What a rider may do is decided in three layers: the phase shipped, a central entitlement per restaurant (with a 24-hour grace copy so riders are never locked out mid-shift when the centre is unreachable), and the role labels under the new Rider App permission module (a seeded Rider Role grants the everyday ones). Superadmins manage the entitlements on a new Rider App Entitlements matrix — every restaurant of a tenant against the feature catalogue.

A branch's selling price group was deciding which items the menu had, so an item the group had never priced vanished from the POS, even though the item was on the branch.

💲 Now: Where a price group sets a price, that price is used • Where the group has no price, the item's base price is used and the item appears • An item with no price at all stays hidden, so no zero-rupee button reaches the till

📱 Also: The customer app's category menu follows the same rule

Result: Items a branch sells stay on the menu.

Rider self-service pages (check-in, check-out, activity) now refuse anyone who is not signed in as a rider — the old check ran too early to see the session and let other staff through.

Delivery addresses keep their pin. When an order arrives with a latitude and longitude (customer app, call centre map), the address row now stores them, so Navigate in the rider app and distance reports have somewhere to go.