Why a delivery attendance check is harder than office attendance

A delivery attendance check sounds simple: did the rider work today or not? In practice the question has four moving parts that office attendance never has. Riders may start from a hub, a dark store or their own home. The same hub runs a morning wave, an afternoon wave and a late-night wave, and one rider may be on one, two or a split of them. Monthly churn in last-mile fleets is high enough that the roster built on the 1st is stale by the 15th. And most rider pay has a per-day component, a per-order component and an incentive tied to days logged, so every attendance entry is directly a rupee amount.

That last point is why delivery attendance disputes are louder than office ones. If a rider is marked absent on a day he completed 38 orders, he loses the day allowance and possibly a weekly incentive slab. If a rider is marked present on a day he did nothing, the fleet operator pays for a ghost. The record has to be defensible in both directions, and it has to be ready on payout day, not reconstructed a week later from WhatsApp groups.

Fleet partners, third-party logistics vendors and dark-store operators feel this most because the platform pays them per delivered order while they pay riders partly by attendance. The two ledgers rarely match without a clean daily record. This guide covers the methods in use, how each one is beaten, and what a rider or driver attendance record needs so that HR, hub leads and riders stop arguing about the same day.

• Riders start from a hub, a store or home, so there is no single gate to watch
• Multiple daily waves mean 'present' has to be tied to a shift window, not just a date
• High churn means new riders must be enrolled in minutes, not through a form
• Day allowance and incentives are computed from attendance, so every entry is money

The four ways delivery companies check rider attendance today

Hub biometric. A fingerprint or face terminal at the hub gate. It works for riders who report to the hub every shift and fails for anyone who starts from home or from a store 20 km away. It also creates a queue at 07:00 when 80 riders arrive together, and most terminals have no idea which wave a rider belongs to, so a 10:40 punch for the 11:00 wave and a 10:40 punch for the 07:00 wave look identical.

WhatsApp photo. The rider sends a selfie with the bike, or a photo of the order bag, to the hub group. The hub lead copies names into Excel in the evening. This is the incumbent system in a large share of Indian fleets because it costs nothing. It is also the least defensible: the photo has no verified time, no verified location, and the Excel is edited by one person with no trail.

App login or first-order proxy. Some operators treat 'logged into the platform app' or 'first order picked up' as attendance. It is convenient because the data already exists, but it measures order activity, not presence. A rider who logged in from home, accepted nothing and logged out counts as present; a rider whose app crashed during the first pickup counts as absent. GPS-plus-selfie attendance in a dedicated app is the fourth method: the rider marks in with a live selfie, the app records GPS and checks it against the hub or store geofence, and the shift window decides which wave the punch belongs to. Read how a delivery staff attendance app works for the mechanics of that flow.

• Hub biometric: strong identity, tied to one location, slow at peak, blind to waves
• WhatsApp photo: free, unverifiable, manual re-entry into Excel every evening
• App login or first-order proxy: measures activity, not presence; disputes on crashes and zero-order days
• GPS plus selfie app: identity, location and time in one record; needs phones with working GPS

How each method gets gamed

Every attendance method is tested by the people it measures within the first week. Knowing the failure modes tells you which controls to add, rather than which method to abandon.

Hub terminals are beaten by punching in and going home; the rider appears for 30 seconds and nothing records that no orders followed. WhatsApp photos are beaten by yesterday's photo, a friend's photo, or a photo taken in the rider's lane at 07:00 while he is still at home. Login proxies are beaten by logging in and rejecting orders until the incentive-day threshold is met. GPS apps are beaten by fake-location apps that place the phone inside the hub; the GPS spoofing glossary entry explains how mock-location tools work and how apps detect them.

The pattern is the same everywhere. A method that captures one signal (identity, or location, or time) is easy to fake alone. A method that captures all three at once and checks them against a shift plan is hard to fake without the hub lead's help, and the hub lead's approvals are themselves logged. That is why the controls below combine signals rather than pick a favourite.

• Punch-and-leave at hub terminals: fix by requiring a punch-out and reconciling attended days with order counts
• Old or borrowed selfies on WhatsApp: fix with in-app live capture and a liveness check
• Login-without-orders on app proxies: fix by keeping attendance and order data separate and comparing them
• Mock-location GPS: fix with mock-location flagging, a tight geofence radius and supervisor spot checks

What a defensible daily delivery attendance record needs

A defensible record is one that HR can show to a rider, a client auditor or a labour inspector and say: this person, at this place, in this window, marked in and out, and here is the evidence. For a delivery fleet that means five elements working together.

First, a hub or store geofence with a realistic radius. A 100 to 150 metre circle around a dark store in a dense market is fine; a 2 km circle is a formality. Riders who legitimately start from home need a separate rule, such as an outdoor-duty start approved by the hub lead, rather than a bigger circle. Second, a selfie with a liveness check so a photo of a photo fails. Third, a shift window: the 07:00 to 11:00 wave accepts punches from 06:30 to 07:30, and anything later is a late start, not a different shift. Fourth, an auto punch-out rule so a rider who forgets to mark out at 23:00 does not appear to have worked 16 hours. Fifth, offline capture that stores the punch on the phone and syncs when the network returns, because basements and hub loading bays rarely have signal.

Put all five in writing as a rider attendance policy, in Hindi or the regional language as well as English, and have riders acknowledge it in the app at onboarding. Under the DPDP Act, location and face data are personal data, so the policy should also state the purpose (attendance and payout), who can see it, and how long it is kept. The delivery attendance check page sets out the same controls as a one-page checklist you can hand to hub leads.

• Geofence per hub or store, radius set to the physical site rather than the pin code
• Live selfie with liveness on every punch-in; identity verified at enrolment against an ID document
• Shift windows per wave with a grace period and a late-start flag
• Auto punch-out after a set number of hours, with the record flagged for review
• Offline punch capture with sync, and a mock-location flag on Android

Payout day: turning attendance into day allowance and incentives

Most fleet pay structures have three layers: a fixed per-day amount for attending the shift, a per-order or per-kilometre rate, and a weekly or monthly incentive that unlocks after a threshold of attended days or orders. Attendance decides the first and third layers. If the record says 22 attended days and the incentive slab needs 24, the difference is real money and the rider will ask for proof.

The cleanest approach is to compute attended days from the attendance system and order counts from the platform, and to let the two disagree visibly. A day with a valid punch and zero orders is an attended day with a productivity problem. A day with 30 orders and no punch is a missing punch that needs regularization, not a silent absence. Handle that second case through a proper regularization workflow with a stated reason, hub-lead approval and an audit trail, and close the window two working days before payout so payroll is not reopened.

Rider-side note, in Hinglish, because riders read these pages too: Agar app mein 'absent' dikh raha hai lekin aapne us din kaam kiya hai, toh usi din ya agle din app se regularization request bhejein. Reason saaf likhein (network nahi tha, phone band ho gaya tha, hub lead ne bahar se duty start karwayi thi) aur us din ke order count ka screenshot attach karein. Hub lead approve karega toh wo din payable ho jayega. Payout ke baad shikayat karne se der ho jaati hai, kyunki tab tak salary sheet lock ho chuki hoti hai.

• Compute attended days and order counts separately; never let one silently overwrite the other
• Set a regularization cut-off two working days before payout and announce it in the app
• Show riders their own attended-day count in the app before payout, not after
• Keep the reason and the approver on every corrected day for audits and incentive disputes

No-shows, replacements and the KPIs a hub should watch

A no-show at 06:45 for the 07:00 wave costs more than the rider's day rate: it costs the orders that slip past the promised slot. Hub leads need to know by 07:05 who has not marked in, and they need a standby list to call. A live monitor that shows present, late and not-yet-punched per hub and per wave is the operational reason to move off WhatsApp, more than any payroll saving.

Track three numbers weekly per hub. Hub fill rate: riders who marked in within the shift window divided by riders rostered. Late-start percentage: punches after the grace period divided by all punches. No-show percentage: rostered riders with no punch and no approved leave divided by riders rostered. A hub with a 90 percent fill rate on paper and a 15 percent late-start rate is not actually filled at wave start. The absenteeism rate formula guide covers how to trend these over time and what usually drives them.

Attend Mitra's GPS attendance app for delivery workers is built for this pattern: per-hub geofences, selfie with liveness, shift templates for each wave, auto punch-out rules, offline capture, mock-location flagging on Android, a live monitor by site and shift, and regularization with approval so payout-day disputes have a record behind them. Attended days and overtime then flow into attendance-linked payroll or export to whatever system pays riders. For a lighter set-up focused on hub-based riders, see the delivery boy attendance app page.

• Live monitor per hub and wave, checked at wave start plus five minutes
• Standby list per hub; log who was called and who accepted the slot
• Weekly: hub fill rate, late-start percentage, no-show percentage
• Monthly: attended days against incentive thresholds, and regularizations per rider