Restaurant Rider Performance KPIs That Drive Better Delivery
The delivery metrics that reveal process problems without encouraging unsafe riding.

Last verified: 2026-08-28
The fastest rider is not automatically the best rider. Useful KPIs separate kitchen delay, dispatch delay and travel while protecting safe behaviour.
Measure the whole delivery
Track assignment-to-pickup, pickup-to-delivery, acceptance rate, rejection reason and completion count. Compare similar zones and times.
Do not reward unsafe speed
Never set a target that encourages traffic risk. Use customer complaints, order condition and accurate status updates alongside duration.
- Safe completion
- Correct handoff
- Reliable updates
Find system bottlenecks
Long assignment-to-pickup time may be a kitchen or packing issue. Review the process before treating every delay as rider performance.
Use rider KPIs to diagnose the delivery system
A rider KPI should identify where service, safety, assignment, handover, proof or cash control needs attention. It should not turn every elapsed minute into an individual score. Restaurant preparation, dispatch timing, distance, traffic, weather, building access, customer response and data quality all affect the trip.
Write a metric dictionary with numerator, denominator, included statuses, time zone, event source, exclusions and owner. If two branches calculate completion differently, a combined dashboard creates false comparisons.
Balanced rider KPI set
Use the set as a diagnostic portfolio. A fast average with missing proof or unresolved cash is not a successful workflow. A high incident-report count can reflect better reporting rather than worse safety; investigate type and action instead of ranking riders by absence of reports.
Do not create a single weighted score until every component has a valid definition and the team understands the incentives. Even then, keep the underlying measures visible.
| Area | Metric | What to verify |
|---|---|---|
| Assignment | Offer acceptance and reassignment | Eligibility and notification context |
| Handover | Ready-to-pickup wait | Kitchen readiness accuracy |
| Delivery | Pickup-to-handover elapsed time | Distance, route and event quality |
| Completion | Delivered vs valid delivery attempts | Cancelled and failed definitions |
| Exceptions | Failure categories and unresolved cases | Responsibility and next action |
| Proof | Required evidence completeness | Privacy and method failures |
| Cash | COD deposit differences | Expected, collected and received |
| Safety | Reported incidents and follow-up | Never reward under-reporting |
Split total delivery time into accountable phases
Break the order into confirmed-to-ready, ready-to-assigned, offered-to-accepted, ready-to-pickup and pickup-to-delivered where the workflow records those events. This shows whether delay begins in production, dispatch, rider response, restaurant handover or the trip. Total order time alone assigns no reliable cause.
Use event occurrence time, not only sync or edit time. Review missing, backdated or impossible sequences before publishing averages. If offline events can sync later, label and reconcile them under the product's tested rule.
Define completion and failure correctly
A completion rate needs a denominator. Decide whether customer cancellations before pickup, restaurant cancellations, test orders, unsupported addresses and duplicate records are excluded, then document it. Do not remove failed attempts simply to improve the result.
Group failed deliveries by factual category: customer unreachable, address issue, refusal, payment issue, damage, safety, restaurant error, rider issue or system problem. The category supports action; it should not automatically assign blame or a payroll consequence.
Separate rider-controlled and contextual evidence
The distinction is not perfect and must be investigated. Use it to ask better questions rather than declare fault from a dashboard. Preserve order IDs and event history for a sampled review.
| Mostly rider-process evidence | Context to review |
|---|---|
| Acknowledged assignment | Notification/device availability |
| Valid status sequence | Offline sync or system outage |
| Handover proof recorded | Customer/method refusal or failure |
| COD deposited under policy | Cashier availability or approved return |
| Exception escalated promptly | Manager/support response |
| Assigned route followed | Traffic, weather, safety diversion |
COD, proof and data-quality KPIs
Measure delivered COD orders with matched expected, collected and deposited amounts, plus unresolved difference value and age under the restaurant's internal controls. Do not combine tips, reimbursements or marketplace settlement with restaurant rider cash. Close each difference through evidence, not a changed order total.
For proof, measure whether required evidence is present and valid for the chosen method. More intrusive evidence is not automatically better. Track privacy exceptions, failed methods and unauthorised customer-data access separately. Data completeness—valid assignment, transition and timestamps—is itself a prerequisite for performance analysis.
Compare like work with like work
Segment by branch, zone or distance band, daypart, order handling type, COD/prepaid, single/batched route and comparable weather or disruption where data exists. Small samples should be shown as small samples rather than converted into a league table. A rider covering difficult or failed routes can look worse in a raw average.
Use medians or distributions where appropriate alongside averages, and inspect outliers. This is analysis guidance, not a claim that one statistical method fits every restaurant. Keep the source rows so a manager can reproduce the comparison.
Set internal targets without inventing benchmarks
This guide does not publish a universal delivery-time or completion target. Build a baseline from the restaurant's verified events, remove data errors, segment the work and set a safe improvement goal the operation can influence. Record the baseline period, exclusions, owner and review date.
A target must never encourage speeding, unsafe parking, phone use while riding, skipped proof, false status or pressure on customers. Treat safety rules and accurate status as non-negotiable constraints.
Weekly rider-operations review
Separate an individual coaching conversation from a process change. If many riders wait at one branch, improve readiness and handover. If one person repeatedly skips an understood status after training and reliable access, use specific order evidence and the restaurant's fair performance process. Record the agreed action, support offered, review date and any corrected event data.
- Check missing and impossible events first
- Review stuck assignments and readiness mismatch
- Sample delayed trips with full context
- Review failure and safety categories
- Reconcile unresolved COD differences
- Check proof and privacy exceptions
- Choose one system or coaching action
- Assign owner and follow-up date
- Confirm whether the prior action worked
KPI dashboard audit questions
- Can every metric be reproduced from order events?
- Are cancelled, failed and returned definitions visible?
- Does event time differ from sync/edit time?
- Can users filter branch, zone and order type?
- Are small sample sizes visible?
- Can a rider or manager flag a data error?
- Are customer and location details access-controlled?
- Does the dashboard avoid unsafe ranking incentives?
Use KPIs for coaching and process design. A balanced score improves delivery without sacrificing safety or trust.
Related guides
- Rider Management System Guide
- Rider Assignment Workflow
- Restaurant KPIs
- Compare Restaurant Management Software
See this workflow in Rosuii: Manage rider operations
Updated:
Frequently asked questions
What is the most important rider KPI?
Should restaurants rank riders only by delivery time?
What are good restaurant rider KPIs?
What is a good delivery-time target?
Should riders be ranked by average delivery time?
How often should rider KPIs be reviewed?
Run your restaurant on Rosuii
POS, menu, inventory, payroll and more — built for Bangladeshi restaurants.
Start free

