Glovo-style Multi-Category Delivery — Custom-Built for Your Market

A hot meal, a substituted grocery and a parcel cannot share one order contract

A customer orders dinner, a neighbor needs replacement milk and a shop wants a sealed parcel collected. All three requests involve pickup and delivery, but their failure paths differ. A kitchen may already have prepared the meal; a grocery picker needs substitution consent; a parcel sender needs evidence of custody. A single delivered flag cannot explain what happened or decide which party should receive money. That distinction should shape the product before the category tiles are designed.

A Glovo-style solution here means an independently branded multi-category delivery product with explicit merchant, courier and customer responsibilities. Glovo is a descriptive reference, not an affiliation or a source of proprietary software, merchant contracts or fleet access. The buying decision is whether your operation can support the selected category contracts, not whether one interface can display many icons. Start with services that have named operators, permitted goods and a support owner.

Choose merchant categories rather than an unrestricted errands promise

Glovo’s published service-model terms distinguish merchant purchases, courier carriage and other service models, and include restricted-item policies. These are useful examples of boundaries, not legal terms to copy into your own operation. Your launch market, goods and contracting relationships require independent review.

Compare the Dunzo-style local errands brief if the central requirement is an open-ended purchase or task instruction. This page instead centers on known categories with defined catalog or parcel inputs. Enabling another category should require a reviewed order contract, handling procedure and incident queue—not a generic instruction field that dispatch must interpret after payment.

Separate baskets when the fulfillment promises differ

A restaurant basket has preparation timing and menu modifiers. A grocery basket has stock uncertainty, pack sizes and replacement choices. A parcel request has sender declarations, pickup details and a destination rather than a merchandise catalog. Let customers understand which transaction they are creating. Where the first release uses separate checkouts, state that clearly and maintain separate receipts, statuses and support references rather than suggesting one combined promise.

Combining categories later requires deliberate allocation of delivery charges, discounts, payments and cancellation outcomes. If dinner is cancelled while groceries continue, the system must not erase both orders or refund a shared charge twice. Define whether a parent purchase groups independent orders or creates one obligation. Buyers should inspect a mixed-category attempt during the walkthrough and see incompatible basket lines refused with an understandable next action, not silently moved into another checkout.

Service zones must qualify the category as well as the address

A customer address inside the general delivery area may still be outside a restaurant’s coverage or beyond a parcel service’s approved route. Store serviceability by category, merchant, pickup and destination. Check opening hours, available capacity and the required handling before a quote becomes payable. Revalidate when the customer changes an address or when a merchant becomes unavailable. A map pin alone does not prove the request can be fulfilled.

Define how boundary changes affect orders already accepted. A new zone rule should not retroactively remove a courier’s destination or rewrite the customer’s quoted charges. Retain the applicable rule version and give operators a resolution path for exceptional addresses. Show customers a specific unavailable reason where safe, rather than offering an optimistic checkout followed by a generic cancellation. Acceptance should include an address served by grocery merchants but excluded from parcel carriage.

Restaurant preparation is a commitment, not an inventory reservation

A kitchen accepting an order may commit ingredients and preparation work before a courier collects it. Keep received, accepted, preparing and ready events distinct, with the responsible merchant and an agreed rejection cutoff. Menu choices and special instructions need merchant confirmation; a customer note is not proof that an allergy or preparation requirement can be met. Preserve the confirmed order when menu availability changes after acceptance.

Dispatch should consume restaurant readiness without pretending it controls the kitchen. Decide what happens when preparation is late, a courier arrives early or the merchant cannot complete the order. Record the decision to wait, replace the assignment or cancel, including financial responsibility under the agreed policy. Do not convert a prepared meal into a returned-stock workflow merely because another category supports returns. The demo should show a late-ready event and the actual customer and courier messages.

Grocery replacements need a separate customer decision

If the requested milk is unavailable, a picker needs more than permission to finish the task. Capture the original pack, proposed alternative, quantity and price difference. Allow the customer to refuse substitution or pre-authorize specific options under agreed limits. Set an approval deadline and an omission rule for silence. Dietary or allergen preferences should remain visible without implying that a matching product label guarantees suitability.

Keep the supplied line distinct from the ordered line so receipts and support can explain the final basket. Reconcile shortages, discounts and any revised amount using the payment provider’s supported workflow. A restaurant modifier and a grocery replacement must not share an approval flag with different meanings. The initial release can omit unavailable lines rather than introduce complex adjusted payments, provided the customer sees the rule and operations can account for the missing goods.

Parcel carriage starts with declared goods and recorded custody

A parcel booking should identify pickup contact, destination contact, declared contents and the handling information the operator requires. Confirm the actual package is eligible before collection; a sender’s declaration does not override prohibited goods or incompatible equipment. Record pickup evidence and the courier who takes custody, with privacy-conscious retention and restricted access. Do not expose recipient details to unrelated merchants or keep photographs longer than the agreed purpose requires.

A failed delivery creates a custody problem even if the app has stopped charging. Define who may authorize redelivery, return to sender or supervised storage, and where the package physically remains while a decision is pending. Closing the task should require the corresponding handoff record or a named unresolved incident. Buyers should test an unreachable recipient and inspect both the customer explanation and the operator’s custody queue before accepting a parcel category.

Equipment and excluded goods belong in dispatch eligibility

A courier eligible for a small food order is not automatically eligible for a fragile parcel or a grocery load requiring different handling. Record the equipment and permitted task categories required by the operator’s reviewed procedures. Apply compatibility at assignment and recheck it when the order changes. Loading incompatible goods into one route should be a deliberate refusal or operator exception, not a convenient default because the same courier is nearby.

The operator must define prohibited goods, package limits, safe transport and training requirements for the market. Software can collect declarations and enforce configured rules; it cannot certify physical handling, insurance or legal permission. Keep restricted categories excluded until their prerequisites have been reviewed and implemented. A simulated disallowed parcel and an unsuitable replacement courier should both be rejected in acceptance, with a clear recovery owner and no invitation to bypass the category through free-text instructions.

Reassignment must know whether the first courier holds the goods

A courier disconnecting before pickup is different from one disconnecting with a meal or parcel already collected. Track assignment versions and custody states separately. Withdraw an uncollected task before offering it to another courier, and reject late acceptance against an obsolete assignment. Once custody has transferred, do not send a replacement to the merchant as though the goods still sit there. Escalate uncertain physical location instead of generating a second collection.

Any permitted courier-to-courier transfer needs an operator-approved handoff procedure and evidence from the relevant parties. Retain the original assignment history rather than editing it away. Repeated notifications and delayed device events must not award duplicate earnings or create conflicting ownership. Demonstrate reassignment both before and after collection, including a stale acceptance event, so buyers can see that the dispatch screen represents physical responsibility rather than merely changing a name.

Quote cancellation and return rules against category events

The Glovo customer FAQ describes different cancellation outcomes for food and non-food requests and connects some charges to preparation, courier assignment or collection. Treat that as an example of event-based policy design, not a fee schedule or return policy for your independent product.

Show your own applicable conditions before confirmation and retain the version accepted by the customer. Recalculate only through an authorized adjustment path with an explanation. A cancelled prepared meal, omitted grocery line and returned parcel should each produce the agreed financial outcome, including who funds it. Keep requested refunds separate from provider-confirmed refunds, and reconcile timeouts before retrying. Merchant settlement and courier earnings need separate entries so one incident does not silently deduct from the wrong party.

Make the demonstration prove category-specific recovery

Illustrative screens explain the intended interface, not verified merchant integration, live courier coverage or access to Glovo systems. Request a connected walkthrough with identified sample merchants, sandbox payments and disclosed simulated providers. Show a meal awaiting readiness, an unanswered grocery replacement and a parcel recipient who cannot be reached. Follow each to the incident owner, customer message and final financial or custody state rather than stopping at successful checkout.

Buyer acceptance should also attempt an incompatible basket, an excluded zone, prohibited goods, unsuitable courier equipment, duplicate payment callbacks and a stale reassignment acceptance. Confirm restricted roles cannot change refund rules or inspect unrelated recipient data. Inspect a merchant payout and courier earning affected by the same incident, and verify that reconciliation does not count the refund twice. Physical operations and provider capacity still require separate validation against the buyer’s actual arrangements.

Bring three order contracts to the scoping discussion

Bring a representative restaurant order, grocery basket and parcel request, together with the intended zones and operating hours. Name who accepts each service, handles goods, resolves incidents and approves money movements. Include one cancellation after preparation, one rejected substitution and one failed parcel handoff. These examples reveal whether the first release can support all proposed categories or should launch with fewer complete journeys.

Use a multi-category delivery scope discussion to agree the release boundary, provider access, operator responsibilities and acceptance evidence. Confirm source ownership, deployment access, third-party licences and support coverage in the agreement; no external brand relationship or delivery outcome is implied.

Review the engineering and handover process for checkpoints around category contracts, connected rehearsals, permissions and incident recovery. A useful launch is one where each accepted request remains understandable when it fails—not simply one with more category icons.