Delivery Stack

Blog

  • From first order to first neighbourhood: a practical delivery launch plan

    From first order to first neighbourhood: a practical delivery launch plan

    Your first delivery zone should be small enough to understand and busy enough to teach you something. Before opening across an entire city, build a service that can take an order, prepare it, assign a rider, and resolve a problem reliably within one neighbourhood.

    This guide walks through a practical pilot for a local grocery delivery business. The same planning questions can help a food or parcel service, but the preparation times, handling requirements, and customer expectations will differ.

    1. Start with a clear delivery promise

    “We deliver groceries” leaves too many questions unanswered. Define who you serve, where you deliver, when you accept orders, and what customers should expect after checkout.

    For a pilot, your promise might be: groceries from a small group of neighbourhood shops, delivered within a defined service area during evening operating hours. Offer a delivery window based on practice runs rather than advertising an exact arrival time before you know the route.

    • Service area: draw the boundary around routes you can actually cover.
    • Opening hours: match your ordering hours to shop preparation and rider availability.
    • Order limits: decide how you will handle heavy bags, fragile products, and unavailable items.
    • Support: give customers one clear way to report a missing item or delayed order.

    2. Build a small, dependable merchant network

    Start with merchants who can keep their availability information current and respond when an order arrives. A large catalogue is less useful if customers repeatedly discover that their chosen products are unavailable.

    Agree on who confirms the order, who approves substitutions, how the bags are labelled, and when the rider should arrive. Walk through these steps with a real basket of products. Record the time taken and the points where someone needed clarification.

    A pilot order is complete only when the customer receives the right items and the merchant, rider, and operator all know what happened.

    3. Make the order journey visible

    Write down the steps from checkout to delivery. For a grocery pilot, a useful sequence is: order received, merchant confirmed, preparing, ready for pickup, rider assigned, collected, and delivered.

    Each step needs an owner. If a merchant cannot fulfil an item, support should know who contacts the customer. If no rider accepts the job, dispatch should know when to intervene. Avoid a situation where every team assumes someone else is handling the exception.

    Use the same order reference across customer communication, shop labels, rider instructions, and support notes. It makes a delayed order easier to trace without asking the customer to explain everything again.

    4. Price the delivery before offering discounts

    Separate the basket value from the money available to cover the delivery. For each completed order, review the delivery fee and any merchant contribution against the rider payout and other variable costs.

    The following is an illustrative worksheet, not a recommended price or a forecast of earnings:

    Item Example amount
    Customer delivery fee ₹45
    Merchant contribution ₹15
    Total revenue available for delivery ₹60
    Rider payout ₹40
    Other variable costs ₹8
    Contribution before fixed costs ₹12

    In this example, a ₹20 promotion funded entirely by the operator changes that contribution to minus ₹8. Office costs, software subscriptions, salaries, and other fixed expenses are still outside the calculation. Replace every number with your own costs before deciding on an offer.

    5. Use the first week to test the whole service

    Give the pilot a purpose beyond collecting orders. A simple first-week plan could look like this:

    1. Days 1–2: rehearse. Run internal test orders, check addresses, practise substitutions, and test cancellation and support flows.
    2. Days 3–4: open to a small group. Invite customers within the service boundary and keep the order volume manageable.
    3. Days 5–7: review and adjust. Compare preparation time, pickup waiting, delivery time, and support issues. Change the step causing the most friction.

    Choose an order cap based on the merchants and riders available during that shift. Increase it only when the team can complete the existing workload without losing track of orders.

    6. Track useful measures

    A compact daily review is enough to begin. Count accepted, completed, and cancelled orders; note the reason for each cancellation; and measure preparation time, rider waiting time, and delivery time separately.

    Also record wrong or missing items, customer support contacts, delivery contribution, and repeat orders. A single average can hide the problem: slow shop preparation needs a different response from a rider struggling to find an address.

    Keep a short incident log with the order reference, the cause, the action taken, and the person responsible for the follow-up. Review it with your merchants and riders before adding another zone.

    A launch checklist you can use today

    • The service boundary and operating hours are visible to customers.
    • Merchants can confirm orders and report unavailable items.
    • Riders have pickup instructions, delivery details, and a support contact.
    • Customers receive useful order updates and can report a problem.
    • Delivery fees and promotions have been checked against actual costs.
    • Someone owns cancellations, refunds, and unresolved orders.
    • The team can review yesterday’s performance before today’s shift.

    A neighbourhood pilot gives you a chance to make the complete service work before extending its reach. Once the order journey is dependable, you can expand with a clearer view of the people, processes, and capacity each new area needs.

    Planning your own launch? Talk to Delivery Stack about the customer, merchant, rider, and dispatch workflows your operation needs.

  • The first ten merchants: building a delivery network people can rely on

    The first ten merchants: building a delivery network people can rely on

    Imagine a rider reaching a shop to collect an order, only to discover that nobody behind the counter has seen it. The customer has already paid. The shopkeeper is busy serving someone else. Support is trying to understand why the order still says “preparing”.

    That scene is a useful test of merchant onboarding. A signed registration form is only the beginning. The real job is making sure the people at the counter know what to do when a delivery order arrives, especially when the shop is busy.

    Choose partners who can keep a promise

    For your first group of merchants, look beyond the size of the catalogue. Ask who will handle incoming orders during each shift, how availability is updated, and whether the shop can prepare an order without leaving walk-in customers unattended.

    A smaller shop with a clear routine may be easier to launch with than a larger one where every delivery request has to wait for the owner. Visit during the hours you intend to operate. You will learn more from watching one busy counter than from discussing an ideal day in a quiet office.

    Agree on the handoff, not just the signup

    Walk through an order together. Decide who confirms it, who packs it, where it waits, and how a rider identifies the right bag. Use an order reference that appears on the merchant screen and the pickup label.

    Set aside a pickup spot that does not block customers or require the rider to search through unlabelled bags. If an order contains more than one bag, mark the total clearly. A pickup instruction such as “two bags, one chilled” gives the rider something specific to check.

    • Order acceptance: identify the person responsible on each shift.
    • Preparation: agree how the shop updates the ready-for-pickup status.
    • Collection: use the order reference and bag count.
    • Exceptions: give the merchant a support contact who can actually respond.

    Practise the unavailable-item conversation

    Grocery orders need a substitution process. Before the pilot opens, ask the merchant to explain what happens if a requested item is unavailable. Does the customer want a substitute? Who checks the alternative price? What happens if the customer cannot be reached?

    Write down the sequence and make the customer’s choice visible. Do not leave a rider to negotiate a replacement at the doorstep. For food orders, rehearse a similar conversation around unavailable dishes or preparation delays, using rules appropriate to that merchant.

    A useful onboarding session ends with the merchant successfully completing an awkward order, not just an easy one.

    Run three orders before calling the merchant ready

    Use one straightforward order, one order with an unavailable item, and one order that needs cancellation or support. These are rehearsal scenarios, not a claim that three orders can reveal every possible problem.

    Watch the process from both sides. Can the shop find the order? Does the rider know where to collect it? Does support see the same status? Fix unclear instructions while everybody is together rather than sending a long explanation after the first customer complains.

    Record the merchant’s operating hours, pickup location, preparation assumptions, escalation contact, and product-handling needs in one place. Confirm what happens when the usual contact is absent. A routine that depends on one person remembering everything is fragile.

    Keep the first review small and useful

    After the first operating week, review missed confirmations, unavailable items, pickup waiting, and customer complaints with each merchant. Ask which part of the process interrupts their normal work. An operator may see a status problem; the merchant may see a device placed too far from the counter.

    Choose one improvement, give it an owner, and check it again during the next shift. The aim is a merchant network that can repeat a dependable routine, not a long list of shops that technically have accounts.

    Before adding the next partner, make sure the current ones can confirm orders, pack accurately, complete the handoff, and reach support. That is the foundation your customers will experience.

    Explore Delivery Stack’s merchant and delivery workflows when you are ready to put that routine into a shared system.

  • When the evening rush hits: a calmer way to run delivery dispatch

    When the evening rush hits: a calmer way to run delivery dispatch

    The hardest order on a busy evening is often the one nobody has looked at recently. It sits between merchant acceptance and rider assignment while each team deals with something more urgent. By the time the customer asks for an update, support has to reconstruct the whole journey.

    Peak-hour dispatch needs a shared view of work and a clear way to intervene. Before changing assignment settings or adding riders, make sure you know where orders are waiting and who is responsible for moving them forward.

    Prepare the shift before it becomes busy

    Check which merchants are open, which riders are available, and which delivery areas the team can cover. Confirm planned breaks and the point at which riders stop accepting new work. A name on a roster is not the same as somebody available for the next pickup.

    Review known disruptions, such as a blocked pickup entrance or a merchant with a limited menu that evening. Give dispatch a way to update that information during the shift. Old assumptions can keep generating assignments that look sensible on a map but are difficult to complete.

    Separate the queues

    Use distinct views for orders awaiting merchant confirmation, orders being prepared, orders ready without a rider, and orders already in transit. Each queue describes a different problem.

    If a shop has not confirmed an order, assigning a rider early may simply move the waiting time to the counter. If several prepared orders have no rider, the useful intervention is to check availability and assignment. If a rider has collected an order and cannot find the address, merchant preparation is no longer relevant.

    Where the order waits First question to ask
    Before confirmation Has the merchant received and reviewed it?
    During preparation Is the preparation estimate still realistic?
    Ready for collection Is there a suitable available rider?
    After pickup Is there an address, route, or contact issue?

    Make every intervention deliberate

    Give dispatch an escalation rule for each queue. The exact time threshold should come from your service promise and observed operating times. Avoid borrowing a number from another business simply because it looks efficient.

    When a dispatcher intervenes, record the reason and the action. Reassigning an order without telling the original rider can create two people travelling to the same shop. Changing the promised delivery window without notifying support can create two different explanations for the customer.

    A useful note is short: “Merchant needs more preparation time; rider told to collect another ready order; customer estimate updated.” It gives the next colleague enough context to continue.

    Be careful with apparently clever shortcuts

    Batching orders can look attractive, but check pickup readiness, route direction, bag capacity, and product-handling needs before combining work. Two pickups on the same street can still be a poor match if one order is ready and the other has not started.

    Do not treat a quicker assignment time as proof of a better delivery experience. A rider can accept quickly and then spend a long time waiting. Measure the complete journey, including time at the shop, rather than optimising the first visible number.

    End with a review the next shift can use

    After the rush, select a handful of delayed orders and trace them through the queues. Look for recurring causes: inaccurate preparation updates, insufficient rider coverage in one area, missing address details, or unclear ownership.

    Choose one operational change for the next shift and record what you expect it to improve. If you change every setting at once, it becomes harder to understand which change helped.

    • Confirm available merchants and riders before opening the busy window.
    • Give each waiting queue an owner and an escalation rule.
    • Communicate reassignment and estimate changes to everyone involved.
    • Review the full delivery journey after the shift.

    A calmer dispatch desk is one where the next action is visible. Discuss your dispatch workflow with Delivery Stack and map the queues your team needs to manage.

  • The second order starts with how you handle the first

    The second order starts with how you handle the first

    A customer places a first order and then waits. They do not know your dispatch process, your merchant network, or how many riders are working. They know the promise they saw at checkout and the information your service gives them afterwards.

    When you plan for repeat orders, start with that experience. A discount may persuade someone to try a service, but it does not answer the questions that appear after payment: was the order received, are the items available, and who will help if something goes wrong?

    Give the first order a clear beginning

    Show the final price, delivery area, and expected delivery window before the customer confirms. Make unavailable items and substitution choices understandable. A customer should not need to contact support just to discover what they agreed to.

    After checkout, confirm that the order exists and explain what happens next. “Order received; the shop is checking your items” describes a real stage. A vague “we are working on it” can leave the customer unsure whether anything has changed.

    Send updates that answer a question

    Choose updates around meaningful events, such as merchant confirmation, a requested substitution, collection, or a change to the expected arrival window. Avoid sending several notifications that all describe the same unchanged situation.

    For a delay, give the customer what you know, what you are doing, and when you will update them again. If you do not have a reliable new estimate, say that the team is checking. An invented precise arrival time can create a second broken promise.

    “The shop needs more preparation time. We are checking the revised pickup time and will update you shortly” is more useful than a confident estimate nobody has verified.

    Make problem reporting feel like part of the service

    Imagine a grocery order arriving with one item missing. Asking the customer to repeat the order number, list every item, and explain the problem to several people turns a small packing error into a tiring conversation.

    Give support access to the order context. Ask for the information needed to resolve the specific issue, explain the available next steps, and identify who owns the follow-up. If a refund or replacement is appropriate under your policy, describe the process and expected timing clearly.

    Record the cause separately from the outcome. “Refund issued” tells you what happened to the customer; “bag left at pickup shelf” tells you which operational step needs attention.

    Invite useful feedback instead of chasing a perfect score

    Keep the first feedback request short. Ask whether the order arrived as expected and make it easy to name the problem. A customer who wants to say “the rider could not find my entrance” should not have to complete a long survey first.

    Read the comments alongside the order history. Several address-related complaints may point to unclear delivery instructions. Several unavailable-item complaints may point to catalogue accuracy. A rating by itself cannot tell you which team should change its routine.

    Measure return behaviour with context

    Define what you mean by a repeat customer and choose a consistent review period. Group customers by their first-order date so that a person who ordered yesterday is not treated the same as someone who has had a month to return.

    Compare first-order experiences within those groups. Check whether delays, missing items, support contacts, or promotions appear alongside different return patterns. Treat the result as a signal to investigate, not automatic proof that one event caused a customer to leave.

    • Was the delivery promise clear before checkout?
    • Did updates match what was actually happening?
    • Could the customer reach someone who understood the order?
    • Was the problem resolved and the operational cause recorded?
    • Are you reviewing repeat orders over a consistent period?

    Before planning the next offer, make sure the first order is an experience you would comfortably repeat yourself. Talk to Delivery Stack about connecting customer updates, delivery status, and support in one workflow.

  • What a delivery fee really needs to cover

    What a delivery fee really needs to cover

    A delivery fee looks simple to a customer: one number at checkout. Behind it is a chain of work that can include preparation, pickup waiting, travel, support, payment processing, and sometimes a failed delivery.

    For an operator, the useful question is whether the revenue associated with an order covers the costs that order creates. Start with a small worksheet you can explain to your team before building a more elaborate model.

    Separate basket value from delivery revenue

    The money collected at checkout is not automatically yours to spend on delivery. Some of it may belong to the merchant. Identify the delivery fee, any agreed merchant contribution, and any other revenue that actually belongs in your calculation.

    Write down how promotions are funded. A customer discount paid by the merchant has a different effect on your delivery contribution from the same discount funded entirely by the operator. Make the funding arrangement explicit rather than leaving it hidden in a campaign total.

    Use a completed-order worksheet

    The following example is hypothetical and is included to show the calculation. It is not a suggested fee, payout, or profitability forecast.

    Completed-order item Illustrative amount
    Customer delivery fee ₹50
    Merchant contribution ₹10
    Total relevant revenue ₹60
    Rider payout ₹38
    Other variable costs ₹9
    Contribution before fixed costs ₹13

    An operator-funded ₹15 offer would take that contribution to minus ₹2. The worksheet still excludes fixed costs such as office expenses, regular salaries, and subscriptions. Use your own records and accounting treatment to decide which costs belong in each category.

    Count the work that does not end in a completed order

    A cancelled order can still involve preparation, rider travel, support time, or a payment adjustment. Record these cases rather than assigning every unsuccessful order a cost of zero.

    Likewise, a failed delivery may involve a return journey or another attempt. Keep the reason visible: an incorrect address, an unreachable customer, a service boundary mistake, and a damaged order need different operational responses.

    Review the costs of these incidents across the operating period. A worksheet for a smooth order is useful, but it does not describe the whole business if difficult orders are excluded.

    Test the difficult parts of the service area

    Distance is one input. Time spent reaching the shop, waiting for collection, finding a building entrance, and completing the handoff also matters when reviewing rider work.

    Compare actual order journeys by area and operating window. If a particular zone regularly creates long collection waits, a higher distance fee may not address the underlying problem. You may need better preparation updates or a different assignment routine.

    Before introducing a new pricing rule, test how it appears at checkout. Make any distance charge, minimum order condition, or promotion limit understandable before payment. A fee that surprises the customer can create support work of its own.

    Review offers as experiments

    Give each offer a purpose, a funding source, a duration, and a review date. Decide what you want to learn: whether people try the service, return without the offer, or order at a different time.

    Look at completed orders and the contribution remaining after the offer, alongside cancellations and support issues. Avoid celebrating order volume without checking what those orders required to fulfil.

    • Identify which checkout revenue belongs to the delivery operation.
    • Record payouts and other variable costs using actual data.
    • Include unsuccessful orders in the operating-period review.
    • Make promotion funding and limits explicit.
    • Check that customers understand the price before payment.

    A clear worksheet gives operations, support, and commercial teams a shared starting point. Explore Delivery Stack to discuss how your delivery rules and order records should work together.

  • When an order falls apart: a practical cancellation playbook

    When an order falls apart: a practical cancellation playbook

    Consider an order that has been accepted by a shop but is still being prepared. The customer needs to cancel. A rider is already travelling to collect it. Each person has a different view of how far the order has progressed.

    If support sees only a cancel button, the next conversation can become a series of guesses. A useful cancellation process starts with the order stage, the work already done, and a clear owner for the decision.

    Show the policy before it becomes a dispute

    Make the cancellation process easy to find before checkout. Explain how customers request cancellation, which order stages need review, and how any payment adjustment is communicated.

    Keep customer-facing wording understandable. Internal terms such as “merchant acknowledgement event” are less useful than a plain explanation of whether the shop has accepted or started preparing the order. Set the actual policy with the appropriate commercial and legal review for your business; this article focuses on the operational workflow.

    Build decisions around the current order stage

    A request before merchant confirmation differs from a request after collection. The team needs to know which stage is current and whether the displayed status matches reality.

    Ask support to verify unclear cases with the merchant or rider rather than treating an old screen status as conclusive. Record the result so the next colleague does not have to repeat the same investigation.

    Order stage Operational check
    Awaiting confirmation Has anyone begun fulfilling the order?
    Accepted or preparing What work has the merchant already completed?
    Rider assigned Has the rider started travelling or waiting?
    Collected Where is the order, and what safe next action is available?

    Tell every affected person what happens next

    Once a cancellation is confirmed, notify the merchant and rider as well as the customer. A cancelled status in the database does not help a rider who is still travelling with outdated instructions.

    Give each notification a clear action. The merchant may need to stop preparing, set aside a packed order, or record a stock adjustment. The rider may need to stop travelling or contact dispatch for the next instruction. Support may need to follow a payment adjustment through completion.

    A customer-facing confirmation should state that cancellation is confirmed, describe any refund or charge under the policy, and explain how to follow up. Distinguish “refund requested” from “refund completed” rather than using the same message for both.

    Handle exceptions without losing the reasoning

    Some cancellations arise from a service problem: an unavailable item, an incorrect estimate, or an order accepted outside the service area. Give support a way to escalate these cases and record who authorised the outcome.

    Use reason codes that explain the cause, then add a short note where the code is insufficient. “Customer cancelled” is too broad if the customer cancelled because the promised item was unavailable.

    A fair operational review asks what happened before deciding who should carry the next action.

    Review cancellations as a service signal

    Group cases by stage and cause. Repeated cancellations before confirmation may point to slow acceptance. Repeated cancellations after substitution requests may point to inaccurate availability. A cluster in one zone may point to a service boundary problem.

    Discuss the pattern with the team that can change it. Do not make support absorb the same problem every evening while the source of the issue remains unchanged.

    • Confirm the order stage and work already done.
    • Give the cancellation decision a clear owner.
    • Notify the customer, merchant, and rider with the next action.
    • Track payment adjustments to their actual outcome.
    • Record the cause and review recurring problems.

    A good playbook makes difficult conversations more consistent. Discuss cancellation and support workflows with Delivery Stack before those conversations become part of every busy shift.

  • Before you open the next delivery zone, make the first one teach you something

    Before you open the next delivery zone, make the first one teach you something

    Opening another delivery zone feels like progress. The map gets larger, more merchants become available, and the team has a new launch to work towards. But the current zone can tell you whether the operation is ready for that extra work.

    Before extending the boundary, look at the service you already run. The question is whether the next area can receive the same dependable handoff, useful updates, and support—not simply whether an address can be added to the app.

    Read the first zone as an operating record

    Review a consistent recent period. Look at merchant confirmation, preparation, pickup waiting, delivery completion, cancellations, and support issues. Keep the busy windows visible rather than relying on an average across quiet and busy hours.

    Choose a few difficult orders and trace them end to end. If the current area still relies on the owner stepping in personally whenever something goes wrong, document those interventions. The next zone needs a routine that other people can follow.

    Walk the new boundary

    A line on a map cannot tell you everything about an address. Test routes between merchants and the proposed delivery area during the hours you plan to operate. Check pickup access, apartment entrances, parking or stopping arrangements, and the instructions customers need to provide.

    Speak to riders about the route. They may know which entrances are confusing, where collection is awkward, or which roads take longer than the map suggests. Treat those observations as things to verify, not as an excuse to make a confident estimate from one trip.

    Plan capacity separately from ambition

    Identify the merchants serving the new area, the riders available there, and the person responsible for dispatch and support. Work out what happens when both areas are busy at once.

    If the same riders serve both zones, define how assignments are prioritised and how the team avoids leaving the original zone uncovered. A shared fleet is a resource with competing demands, not spare capacity that automatically appears when the boundary expands.

    • Merchants: which shops can prepare orders for the new area?
    • Riders: who can cover the operating window without abandoning existing work?
    • Dispatch: who watches orders waiting at the boundary?
    • Support: who owns incidents when a route or address is unfamiliar?

    Open with a limit you can explain

    Start the new zone with operating hours and an order cap that match the team available. Make those limits clear to customers and merchants. A controlled pilot is easier to review than an unrestricted launch that immediately creates a backlog.

    For example, a team might begin with one evening window and a small merchant group, then review the completed journeys before extending the hours. This is an illustrative approach, not a universal launch schedule. Choose the limits from your own capacity and service promise.

    Write down what would make you pause the pilot: repeated missing updates, unresolved pickup delays, inadequate rider coverage, or support problems the team cannot close. Decide who has authority to pause new orders while existing ones are completed.

    Compare zones without hiding the difference

    Keep the new area’s performance visible in its own review. A strong result in the original zone can hide a weak result in the new one when everything is combined.

    Check preparation, waiting, delivery time, unsuccessful orders, and delivery contribution for both areas. Ask whether the new boundary creates extra travel or different customer expectations. If it does, adjust the operating plan rather than forcing both areas into the same assumptions.

    The next zone should inherit a working routine, and then be allowed to teach you where that routine needs to change.

    After the pilot, write a short decision: keep the current limit, expand it, change the boundary, or pause. Include the evidence and the owner of the next action. It gives the team a practical reason for the next step.

    Plan your next delivery area with Delivery Stack and map the merchant, rider, dispatch, and support workflows that need to grow with it.