Dunzo-style Local Errands — Custom-Built for Your Market

An extra stop is a new agreement, not a message to the courier

A requester books a document pickup and then asks the courier to buy household supplies on the way. The new stop adds spending, waiting and a different handoff. If those instructions exist only in chat, dispatch cannot reliably explain the final price, prove purchase consent or decide who should pay when the recipient is absent. A hyperlocal errand product needs a bounded task agreement that can change visibly, not an unrestricted request box attached to a moving vehicle.

Dunzo is used here as a historical category reference for an independently branded local errands product. This page does not offer an active Dunzo demo, affiliation, its courier network or proprietary implementation. The proposed scope connects permitted tasks, purchase authorization, pickup permission, courier expenses and delivery recovery. Select a narrow operating area and task category first; ownership, supplier access and commercial arrangements must be confirmed for your own business.

Turn the request into a task that someone can safely accept

Ask whether the courier is collecting a ready package, buying named goods or returning something already delivered. Those tasks have different permissions and financial responsibilities. Capture item description, approximate dimensions where relevant, pickup location, contact authority, destination and a time expectation. Mark unknown details for confirmation. Free text can supplement a structured brief, but it should not override category restrictions or conceal an unsupported purchase inside otherwise ordinary instructions.

Compare the DoorDash-style merchant ordering brief when the principal flow begins with a merchant catalog and a prepared order. This errand brief begins with a customer-defined task, so it needs stronger revision and expense controls. Do not combine the two flows until operators can identify who sells the goods, who authorizes collection and who owns each failed-stop decision.

Check eligibility again when the actual goods are known

A request described as a small parcel may contain an unsuitable load or prohibited item when the courier arrives. Define the task exclusions, vehicle limits and inspection or declaration steps with the responsible operating and legal teams. Restrict goods or activities outside the launch scope rather than accepting them through a generic miscellaneous category. Make the policy understandable to requesters and couriers, with a reasoned rejection and a support path that does not pressure someone to proceed.

Eligibility is not a one-time checkbox. Recheck it when goods, pickup instructions or route change. A customer adding a restricted item after assignment must not bypass the original review. Record the rejected revision separately from the accepted task and decide whether the remaining errand can continue. Software can enforce an agreed policy and retain decisions; it cannot establish licensing, insurance or lawful physical transport merely by presenting a warning.

Make the purchase cap separate from the delivery estimate

The goods budget and service fee are different amounts. Explain whether the requester pays a merchant directly, authorizes a card hold or reimburses a courier who advances permitted funds. Define a purchase cap, applicable currency, allowed item changes and who can approve an increase. A courier should see the remaining approved amount before purchase, while the requester sees the impact of substitutions or unavailable goods without confusing it with a higher route fee.

The Stripe authorization and capture documentation distinguishes reserving funds from collecting them and explains that eligibility and authorization expiry vary. If this model is selected, confirm the supported payment method and capture boundary for your account. An approved task budget is not proof that a payment hold succeeded or that an increased purchase amount can be collected.

A receipt supports an expense; it does not approve it

Retain the merchant, purchase time, item lines and relevant receipt evidence against the task expense. Separate the amount requested, amount approved, amount spent and amount reimbursed. A photograph of a receipt alone does not establish that its goods belong to this task, that the price was authorized or that the courier has not claimed it elsewhere. Give finance a way to flag duplicates, unclear totals and purchases outside the accepted cap before reimbursement.

Choose the minimum information needed to resolve expenses. Receipts can reveal personal purchases or contact information; restrict access and redact unrelated material where the agreed process requires it. Record a reviewer and reason for manual adjustments, and make disputed expenses visible without rewriting the original evidence. If cash handling is in scope, define the advance, change returned and reconciliation owner. Do not put an unsupported wallet into the first release simply to hide these distinctions.

Pickup permission must survive a change of contact

The requester may not be the person holding the package. Record who can release it, what reference or verification they require and whether collection is already approved. A courier arriving at an office reception should not rely on an unrelated customer chat as authority to take documents. Show pickup instructions to the assigned courier only as needed, and capture collection confirmation without exposing sensitive package contents to every operator.

When the pickup contact changes, retain both the earlier and revised instructions with the approver. Do not silently replace authority after a failed collection. Agree what the courier does if the package is unavailable, the contact denies permission or the item differs materially from its description. A failed pickup is not a successful task followed by a refund; it needs its own custody state, waiting decision and disclosed fee treatment.

Version every material multi-stop task revision

Adding a pharmacy stop, changing the destination or requesting a return affects more than route distance. Review task eligibility, expense consent, handling requirements and courier acceptance again. Keep the accepted stop sequence attached to a version so dispatch can distinguish a new proposal from the work already underway. Show the revised charge and expected execution boundary before confirming it. The courier needs a safe way to decline work outside the accepted assignment.

Preserve stop dependencies: an item cannot be returned before collection, and a purchase should not proceed when the requester has declined its revised price. If concurrent edits arrive, resolve them against the current accepted version rather than merging incompatible instructions. Keep previously completed stops immutable and record which remaining steps changed. Acceptance should demonstrate a requester edit arriving while dispatch is reassigning the task, with no duplicate collection or contradictory destination.

Custody is a sequence of handoffs, not a map trace

Record collection, any transfer between couriers, recipient handoff and return as separate custody events. Identify the item or package reference, responsible participant, time and permitted evidence at each step. Location history can support investigation, but a pin near the destination does not establish that the correct recipient received the goods. Reassignment must account for where the package actually is before a replacement courier receives the next instruction.

The Uber Direct verification guide describes pickup, delivery and return verification options such as signatures, barcodes and pictures. It is a technical example, not a commitment that this product includes Uber access. Select evidence appropriate to the task and provider, define retention and restricted access, and avoid collecting unnecessary identity material simply because an API can accept it.

No response needs a deadline and a recovery owner

A courier cannot wait indefinitely while a customer decides whether to buy an alternative item. Agree the communication attempts, response boundary and safe waiting location for each task type. When consent is missing, pause or omit the proposed purchase under the disclosed policy rather than treating silence as acceptance. Record what was attempted and assign dispatch responsibility for the next decision. The requester should receive a clear explanation of what remains incomplete.

An absent recipient is different from an unreachable buyer during purchasing. Goods may already be in custody and may need return to an authorized origin. Define whether unattended handoff is permitted, which evidence is required and which categories exclude it. Never route every case to a leave-at-door default. Include after-hours support ownership, courier contact protection and a resolution for notification failures so the system does not depend on one successful message.

Returns and price disputes need separate financial outcomes

A merchant accepting returned goods does not necessarily mean the payment has been refunded. Track the physical return reference, merchant decision, customer payment outcome and courier reimbursement separately. Identify who may authorize the return journey and how its fee is disclosed. If a merchant refuses a return, keep the custody and expense case unresolved with a responsible operator instead of closing it as delivered merely to remove it from the queue.

For a price dispute, compare the accepted budget and revision history with the receipt and provider record. Explain whether the disagreement concerns goods, service fees, waiting time or an unsupported courier expense. Restrict overrides and retain the reviewer reason. A provider timeout should trigger reconciliation before retrying a charge, refund or reimbursement. Preserve identifiers so duplicated callbacks cannot pay the same expense twice or make the customer pay for a rejected task revision.

A useful demo must include a task that cannot finish as requested

Illustrative errand screens help explain the customer and courier journeys; they are not evidence of a live brand service, available courier fleet or connected merchant. Ask for a connected walkthrough with identified sample items and sandbox money. Begin with a permitted pickup, propose an added purchase above its cap, deny collection permission at one stop and make the final recipient unavailable. Inspect the customer explanation, courier instruction and operator recovery queue at every boundary.

Buyer acceptance should include a prohibited-task revision, a duplicate receipt, a stale assignment, unanswered purchase approval and a failed return refund. Test that restricted roles cannot approve their own expense claims or erase handoff evidence. Confirm task versions, custody owners and provider reconciliation remain consistent when events repeat or arrive late. Demonstrated screens should distinguish simulated integrations from verified accounts; operational readiness still requires suitable couriers, reviewed policies and market-specific responsibilities.

Bring one permitted errand and one failed handoff to scoping

Bring a representative task brief, pickup permission, purchase cap, redacted receipt and an agreed destination. Include a revised stop, unreachable contact and return decision. Name the dispatch owner, expense reviewer and customer-support authority. These inputs show whether the first release can use direct merchant payment and a single pickup, or needs courier advances and more complex reconciliation. Define provider access, handling exclusions and the buyer’s operating responsibilities before discussing expansion.

Use an errand-platform scope discussion to agree launch categories, task revisions, acceptance evidence and financial boundaries. Confirm source ownership, deployment access, third-party terms, evidence recovery and support coverage in the applicable agreement.

Review the delivery process for checkpoints around policy definition, connected rehearsal and operator handover. The first release should complete or safely recover a bounded errand with every purchase and handoff accounted for, rather than promising to do anything a requester types.