Riders and delivery

Menu: Sell → Dispatch · Setup → Employees, Delivery failures Who: owner, branch manager (an agent sees it, read-only)

A rider is an employee

Not a user and not a role — most riders never log in. Setup → Employees, tick Rider. They get the code, the CNIC and photo, the joining and leaving dates, and the effective- dated salary rows every employee has. Re-hiring somebody brings their history back with them.

A rider belongs to the outlet they ride out of. A head-office employee cannot be one, and a commissary dispatches nothing — it has no till.

Where the food is

Dispatch is its own thing, not an order status. Only a delivery order has one:

pending  →  assigned  →  out  →  delivered
                              →  failed

Backwards is refused, and delivered and failed are the end — with one exception: assigned back to pending, because a rider who calls in sick has to come off the order and that is not a failed delivery. The food never moved.

Stock leaves when the food does

Stock is deducted when the order goes out, not when it is paid. Food in a bag on a motorbike while the shelf still says it is in the building means the till sells the last of a cheese that has physically left.

Dine-in, takeaway and retail are unchanged — they still deduct at payment.

A failed delivery puts the stock back.

When the money is taken

delivery.pay_on_return (per branch, on by default): the sale is paid when the rider comes back. While the food is out the order is placed and unpaid, so the drawer never shows cash the shop has not got, and a failed delivery never has to be un-sold.

Switch it off for a counter that takes the money first.

The card machine goes out with the rider. Nothing is prepaid — no card over the phone, no payment link.

The dispatch screen

One branch, one business day. Assign a rider, mark out, then delivered or failed.

A failed delivery needs a reason from your own list (Setup → Delivery failures). The order is voided — stock back, no money was taken — but the failure is written down beside it, because a void answers what happened to the money and says nothing about why the food came back. The reports count failures apart, or "on time %" is quietly computed over the deliveries that went well.

A second attempt is not in Sellify. Ring the order in again.

Settling a rider's cash

Per rider, per business day. The rider hands over what they collected and you type one figure — Counted from their hand.

Settling is per rider, so somebody who finishes at 9pm does not wait for a rider still out. Settling twice moves the same row.

A delivery nobody has rung in yet blocks the settlement, naming how many. Its cash is invisible to us until the cashier takes the money, and settling over it would measure the rider against a figure short by exactly that order.

A day will not close with an unsettled rider, named.

The Z report

Carries by rider beside by terminal. A variance of blank means nobody counted it — never zero, because "nothing missing" and "nobody counted it" are different answers.

The reports

Reporting → Reports, under Delivery:

• Delivery performance — on time, late, failed, and the average minutes against the promise
• Rider performance — with the cash variance
• Failed deliveries — names the customer, so it is never shown to the AI assistant

Two things these refuse to do: a failure is counted apart, never inside the on-time count; and a delivery nobody promised anything for is unmeasured, with a column of its own, staying out of the average entirely. On-time % reads blank rather than 100 when nothing was measured — a shop that promised nothing was not perfect, it was unmeasured.

What Sellify does not do

No maps, no coordinates, no live rider location, and no rider app. The transitions are an API, so an app can be built on them later.