Job in. Driver out.
Cash reconciled before anyone goes home.
Cash reconciled before anyone goes home.
Six stages, two weeks to cutover
Six stages. Everything between the order landing and the money being counted.
By API from your storefront, by CSV upload, or typed into the dispatch console. A job is an address, a time window, a vehicle class and a payment method — nothing more.
New address: the driver drops a pin on first successful delivery. Returning address: it routes straight to the saved coordinates. Over a few months the guesswork disappears from your operation.
Jobs cluster by geography and time window, then sequence into runs sized to the shift. A job added at 11am reshuffles the afternoon automatically rather than waiting for tomorrow's plan.
The app shows one stop at a time. Navigate, arrive, capture proof, next. Everything queues offline and syncs when signal returns, because half of Dubai delivery happens in basement car parks.
A live map on your own domain, with your logo. SMS and WhatsApp on dispatch and on approach. The customer never sees our name.
Each driver's expected cash is calculated from their completed COD jobs. They declare, the system compares, and any variance is flagged before they go home — not discovered three weeks later in accounts.
| WEEK | WHAT HAPPENS | WHO DOES IT |
|---|---|---|
| 1 | Account setup, zones drawn, vehicle classes and time windows configured, drivers onboarded to the app | Us, with your ops lead |
| 1 | Storefront connected by API, or the CSV template mapped to your existing export | Your developer, ~4 hours |
| 2 | Parallel run — one zone live on DeliverPin, everything else on your current process | Your dispatcher |
| 2 | Tracking page branded and pointed at your subdomain, SMS and WhatsApp templates approved | Us |
| 3 | Full cutover, old process retired | Everyone |
Indicative timeline for an operation running under 2,000 deliveries a day with a single warehouse.
The developer documentation shows the actual endpoints, payloads and webhooks.