01 - Context & Background
Why Pathao needed a new order type
Pathao Food is one of Bangladesh and Nepal's leading food delivery platforms. By 2025, the core delivery product was mature - but a structural gap had emerged: Pathao had exactly zero answer for users who didn't want a rider. Every single order required dispatch logistics, regardless of whether the user was 200 metres from the restaurant or eating in five minutes.
Competitor analysis painted a clear picture. Foodpanda, Foodi, Uber Eats, and DoorDash all offered Pickup as a standard mode. Delivery fees of ৳50–100 per order were a documented deterrent for price-sensitive urban users, particularly in high-frequency ordering segments. The market signal was unambiguous: this was a revenue channel being actively surrendered.
The gap
Zero pickup offering
100% of orders required rider dispatch. Cost-sensitive users had no alternative but to order elsewhere or not at all.
Market signal
Competitors already there
Foodpanda, Foodi, Uber Eats, and DoorDash all ship pickup as standard. This was table stakes being missed.
User pain
Fees deterring orders
Delivery fees of ৳50–100 deterred frequent ordering among urban millennials and Gen Z - Pathao's core growth segment.
Strategic alignment: Pickup mapped directly to the 2025 Q3–Q4 OKR of expanding revenue channels in the Food vertical through non-delivery order types - a first-time GMV diversification play for Pathao Food.
02 - Problem Statement
The structural delivery dependency
Core problem
"Pathao Food is a delivery-only platform in a market that has moved to hybrid." Every order locks in rider costs, limits peak-hour capacity, and excludes users who could be 5-minute walks from the food they want.
The problem had three distinct dimensions that needed separate solutions:
User dimension
Fee sensitivity blocking frequency
Urban millennials and Gen Z placed fewer orders because delivery fees made casual, everyday ordering economically unattractive.
Ops dimension
Rider pressure at peak hours
All order volume funnelled through the rider network. Peak-hour scarcity meant orders failed or slowed precisely when demand was highest.
Platform dimension
Single revenue model
Pathao's Food GMV was entirely delivery-dependent. A new order type meant a new GMV lever that didn't compete with the existing one.
Failure modes to design around
Low restaurant adoption - if restaurants didn't participate, the discovery surface would be empty and users would churn immediately. A restaurant-first activation strategy was non-negotiable.
Operational confusion - restaurants handling delivery and pickup orders in parallel without clear separation would create fulfilment errors and preparation delays.
User no-shows - unlike delivery, there's no rider to close the loop. If the user doesn't appear, the restaurant bears the cost. The system needed explicit no-show handling from day one.
Refund ambiguity - pre-payment without delivery confirmation creates refund complexity. Every cancellation scenario needed a defined refund path before launch.
03 - Target Personas
Who we were designing for
Pickup attracts a fundamentally different user than delivery. The mental model shifts from "bring it to me" to "I'll come to you." Two primary personas drove the product decisions.
AH
The Affordability-Hunter
Urban millennial, Dhaka · Orders 8–12x/month
Goal
Order food daily without delivery fees eating into their budget
Behaviour
Works near dense restaurant areas. Checks Pathao during lunch and evening. Often passes restaurants on commute.
Pain
৳50–100 delivery fee makes Pathao a "special occasion" app, not a daily habit
Quote
"The restaurant is right downstairs. Why am I paying ৳80 for someone to walk it up?"
SR
The Speed-Seeker
Gen Z, Chittagong · Orders 4–6x/month
Goal
Get food faster than delivery during peak hours without waiting for a rider
Behaviour
High-frequency app user. Frequently frustrated by peak-hour delivery delays of 45–60 minutes. Values speed over convenience.
Pain
Peak-hour delivery is unpredictable. Would rather pick up if they knew the food was ready
Quote
"Just tell me when the food is ready and I'll be there. Don't make me wait for a rider who's 20 minutes away."
04 - Product Strategy
The core decisions that shaped the product
Decision 1 - Pre-payment only, no COD
Without a rider to verify collection, cash-on-delivery creates an unresolvable fulfilment loop. The restaurant prepares food with no guarantee of payment. Pre-payment was both the right UX choice - it creates commitment and reduces no-shows - and the operationally necessary one. Supported payment methods: Pathao Pay, BNPL, and digital payments. COD explicitly disabled for all pickup orders.
Decision 2 - Restaurant-First Dispatch as a prerequisite
Pickup was built on top of Resto-First Dispatch (RFD) - the ordering model where restaurants confirm and prepare food before dispatch. This was a conscious dependency decision. RFD restaurants had already demonstrated operational reliability. Enabling pickup for a restaurant required RFD to already be active - this single constraint dramatically reduced the risk of operational failure on launch.
Decision 3 - Two discovery surfaces, not one
Rather than just adding a filter to the existing Food Home, we introduced a dedicated Pickup tab in the bottom navigation. This created a clean, separate mental model for users and a controlled surface for restaurant discovery. Map view was built in from launch - pickup is inherently location-driven, and users need to see where they're going.
Decision 4 - No pickup-to-delivery switch at checkout
Mode switching was locked to the restaurant screen, not checkout. This prevented last-minute order-type confusion, kept the checkout flow clean, and ensured the delivery fee logic (or absence of it) was set before the user committed to items.
Phased approach: Phase 1 (approved) shipped core pickup: discovery, order placement, real-time tracking, restaurant management, and payments. Phase 2 (planned) would add scheduled pickup, pickup-specific discounts, and co-subsidy models. This sequencing kept the launch scope manageable and let us validate demand before adding complexity.
MVP scope decisions - what we explicitly cut
Food Web pickup support - cut from Phase 1. Requires Digital Payment, Pathao Pay, and BNPL prerequisites on web that would significantly extend the timeline.
Expanded search result discovery - cut from Phase 1. Adding pickup restaurants to search results would have increased the complexity of an already in-progress search revamp.
Pickup-specific discounts - moved to Phase 2. Discount logic across delivery mode separation required significant ops dashboard rework that didn't need to block core launch.
05 - Feature Breakdown
What was built, and why each piece mattered
| Feature |
User Story |
Key Design Decisions |
Priority |
| Pickup Discovery & Explore |
Browse pickup-enabled restaurants based on location |
Dedicated Pickup tab in bottom nav (city-level configurable). Map view with restaurant pins. Location-based sorting. Pickup indicator on restaurant cards. Collection-scoped search and filters. Mode switch locked to restaurant screen - not checkout. |
Must Have |
| Real-Time Order Tracking |
Know exactly when to head to the restaurant |
Four statuses: Pending → Placed → Food Ready → Delivered. Token ID displayed when food is ready for frictionless handover. Smart notifications at 50% and 100% of prep time. Google Maps deep-link for navigation. No rider info section - replaced with restaurant contact. "Picked Up" button available after acceptance, even before restaurant handover. |
Must Have |
| Bill & Pre-Payment |
See savings clearly; pay securely before order confirms |
Delivery fee and tip lines removed from bill. Delivery-fee promos suppressed. Payment flow: Place Order → Payment Screen → Success → Ongoing Order. On payment failure, user returns to checkout with error - order not placed. Supported: Pathao Pay, BNPL, Digital Payment. |
Must Have |
| Order History & Reorder |
Reorder a favourite pickup meal with one tap |
Pickup label on history items. Mode memory on reorder - pickup reorders default to pickup, delivery to delivery. Alert if pickup is disabled for that restaurant, with delivery fallback prompt. Food Web blocks pickup reorders with redirect to app. |
Must Have |
| Order Cancellation & Refunds |
Cancel if plans change; get a refund where applicable |
Cancellation allowed before restaurant accepts. Refund eligibility rules clearly defined: auto-refund to escrow for Pay/BNPL; manual daily sheet process for digital payments. No refund for user no-show or user-initiated CX cancellations. Disclaimer surfaced in-app. |
Must Have |
| No-Show Handling |
Protect restaurants when users don't appear |
Restaurant can mark "No Show" after n hours of food ready. System auto-marks No Show at end of day for uncollected orders. No-Show = order marked delivered. Engine Room can also mark No Show on behalf of restaurant. |
Must Have |
| Restaurant Location & Directions |
Find the restaurant without any friction |
Address and map shown at order confirmation. Deep-link to Google Maps with user-to-restaurant route pre-loaded. |
Must Have |
| Review & Rating |
Rate the food - not the rider who wasn't there |
Driver rating removed from pickup order rating flow. Food rating only - keeps the review relevant and clean. |
Must Have |
06 - User Journey
The ideal end-to-end pickup experience
The designed flow removed every moment of ambiguity that caused failure in early prototypes - particularly around payment confirmation, the moment to leave for the restaurant, and handover identification.
1
Discovery - Pickup Tab or Map View
User taps the Pickup tab in the Food bottom nav. Restaurants sorted by proximity to their set location. Map view available for spatial scanning. Pickup indicator badges on all eligible restaurant cards. Filter applies to restaurant collections, not delivery-based options.
2
Menu Browse & Cart
User selects a pickup-enabled restaurant. Delivery mode locked to Pickup. No delivery fee shown anywhere in the UI. Mode can only be changed here - not in checkout. User builds cart normally.
3
Checkout & Pre-Payment
Bill breakdown shows items only - no delivery fee, no tip. Delivery-fee promos suppressed. User taps Place Order → taken to payment screen. Payment via Pathao Pay, BNPL, or digital payment. On success, order placed and user enters ongoing order screen. On failure, user returns to checkout with clear error - order not created.
4
Tracking - Pending to Accepted
Status: PENDING until restaurant accepts. Once accepted: PLACED. Estimated ready time shown prominently. No rider section - restaurant contact info shown. "Picked Up" button available (can tap before restaurant handover). Map shows user and restaurant positions. No route shown in-app - Google Maps redirect for navigation.
5
Timing Notifications - Leave at the Right Moment
At 50% prep time: "Your food is almost ready! Time to head out." At 100% or restaurant handover (whichever first): "Your order is ready! Pick it up from [Restaurant Name]." These notifications replace the job the rider dispatch normally does - creating the moment of action for the user without requiring live ops involvement.
6
Handover - Token ID as the Identifier
When food is ready, a Token ID appears in the ongoing order screen. User shows/quotes the token at the counter - removes dependency on name matching or app screenshots. Restaurant staff identifies the order instantly. No ambiguity, no queue confusion.
7
Pickup Confirmation & Loyalty
User taps "Picked Up" - order marked DELIVERED. Sancus loyalty points credited. Rating screen shows food rating only (no rider rating). Order appears in history with Pickup label, reorder defaults to pickup mode.
Before vs. after: the ordering friction table
| Phase |
Before (delivery only) |
Emotional state |
After (with Pickup) |
| Decision |
Checks delivery fee. ৳80 feels steep for a quick lunch. |
😕Fee friction |
No delivery fee. Decides to pickup. Order starts immediately. |
| Waiting |
45-minute wait, uncertain if rider is coming. |
😤Uncertainty |
Prep time shown upfront. Notified at 50% and 100%. Knows exactly when to leave. |
| Arrival |
No equivalent - food arrives at door. |
- |
Token ID displayed. Walk up to counter, quote token. No queue confusion. |
| Completion |
Rates food and rider. |
😐Irrelevant prompt |
Rates food only. Loyalty points credited. Reorder defaults to pickup. |
07 - Notification System
Replacing the rider with smart timing
In delivery orders, the rider implicitly signals the user when the food is near. In pickup, there's no rider - so the notification system had to carry that entire behavioural trigger. Every notification was mapped to a specific user action we needed to drive.
1
Restaurant accepts order
"Your order is being prepared and will be ready at 1:30 PM." → Sets expectation. Anchors the user to a time.
2
50% of prep time elapsed
"Your food is almost ready! Time to head out and pick it up." → Creates the leave-now moment. Prevents users from arriving too early or too late.
3
Prep time complete OR restaurant clicks Handover (whichever first)
"Your order is ready! Pick it up from [Restaurant Name]." → The critical action trigger. Drives foot traffic at the right moment.
4
X minutes after ready - food not picked up
"Reminder: your food is ready at [Restaurant Name]. Please collect it soon." + SMS fallback. → Protects restaurants from cold food and no-shows. Also triggers internal Pathao Talk channel alert for ops visibility.
5
User confirms pickup
"Enjoy your meal! Your order is complete." → Closes the loop positively. Triggers loyalty point credit.
6–8
Cancellation / No-Show scenarios
User cancel: "Your pickup order has been cancelled successfully." · Restaurant cancel: "Your order at [Restaurant Name] was cancelled. A refund will be processed shortly." · No-show: "Your order was not collected and has been closed. Please contact support if needed." → Each path has a defined message so no user is left in ambiguity about order state or refund expectation.
08 - Restaurant & Ops Tooling
The other side of the product: restaurant and ops experience
A pickup product is only as good as the restaurant's ability to manage it. Most failed pickup launches in competing apps had one root cause: restaurants didn't have the tools to separate and communicate pickup order status clearly. We built this side as a first-class product surface, not an afterthought.
Restaurant portal
Dedicated pickup order panel
Pickup orders clearly marked with a "Pickup" identifier. Separate panel or filter for pickup vs. delivery. User photo, name, and mobile shown - staff can identify the user at handover. Order marked pre-paid to remove payment confusion. Handover button triggers user notification. Printable receipt includes pickup-specific fields.
Food ops dashboard
Pickup enable / disable controls
Toggle per restaurant to enable/disable pickup - requires RFD active. Bulk enable/disable for multiple restaurants simultaneously. CSV upload support with new pickup column (True/False). Cache propagation: changes reflect within 5 minutes. Chain restaurants require RFD handle to be configured first.
Engine room
Internal order management
Delivery mode (Pickup/Delivery) visible on all orders. Rider info section blank for pickup orders. Manual pairing, appease-to-driver, and foodman sections all unavailable. Route shows user-to-restaurant only. Order status manually changeable: Placed → Food Ready → Delivered. No-Show markable on behalf of restaurant after user confirmation.
Restaurant criteria
Eligibility gates for quality
Only restaurants meeting all three criteria eligible for pickup: (1) already onboarded to RFD, (2) cancellation rate below 5%, (3) high item hygiene rate. This ensured the initial restaurant list was operationally ready - not just willing.
09 - Success Metrics
How we defined and measured success
North Star
GMV uplift from Pickup orders
+20%
Total order volume uplift · 3 months
Acquisition
MAU growth driven by Pickup
+15%
Monthly active users · 3 months
Conversion
Pickup tab view → completed order
12%
View-to-order conversion rate
Adoption
MAUs engaging with Pickup tab
20%
Of total MAUs · by Sep 29, 2025
Supply
Restaurant adoption rate
60%
Active restaurants enabling Pickup · 4 months
Quality
User satisfaction score
4.0+
Avg rating for pickup orders · 6 months
Partner
Restaurant revenue uplift
+10%
Avg revenue for partnered restaurants
Frequency
Orders per user per month
+10%
Average order frequency · 3 months
Ops efficiency
Delivery operational cost reduction
-10%
From delivery-to-pickup order shift · 6 months
Analytics events instrumented (Firebase)
FV2_VisitPickUp - tap on Pickup in bottom nav · FV2_VisitPickUpMap - open map view · FV2_ClickPickUpRestaurant - restaurant tap (with source: PickUpHome / PickUpMap / PickUpMapRestoList / SearchRestaurantTab / SearchItemTab) · FV2_Checkout - extended with delivery_mode parameter · FV2_MenuItemAdd / FV2_MenuItemAddMP - both extended with delivery_mode. This event instrumentation was defined in the PRD to ensure funnel analysis was available from day one of launch.
10 - Go-to-Market
How we took it to market
GTM for a new order type is operationally heavy - it's not just a feature release. It required simultaneous restaurant onboarding, CX training, billing process design, refund workflows, and analytics dashboard preparation. All workstreams were tracked in a shared task tracker with named owners and hard deadlines.
01
Restaurant List Preparation
Hunt list and confirmed list built by ops. Eligibility gating applied: RFD active, cancellation rate <5%, high item hygiene. Preparation times tuned. Addresses verified and updated with floor/location details.
02
Process & SOP Build
CX and RCM SOPs drafted for order disputes, no-show handling, wrong/cold food complaints, and payment discrepancies. KAM SOP for weekly prep time monitoring. Refund process defined and finance team aligned on daily manual refund sheet.
03
Training
Training materials prepared for restaurants, CX, and Ops. KAM, Ops, and CX training completed. Restaurant training sessions run. All stakeholders confirmed ready before feature toggle activation.
04
Launch & Monitor
Pickup enabled for confirmed restaurant list. Analytics dashboard live with Pickup tag. Daily refund sheet process active. Restaurant billing format and periodic billing cycle confirmed. Marketing GTM plan executed in parallel.
Phased city rollout: Initial launch targeted Dhaka, Chittagong, and Kathmandu - cities with sufficient restaurant density and urban user concentration to generate meaningful pickup adoption data before a broader rollout.
11 - Risk Management
Risks identified and mitigations designed
High Risk
Low restaurant adoption at launch
Mitigated by pre-qualifying the restaurant list (RFD, cancellation rate, hygiene), offering lower commission rates, and running KAM-led onboarding before launch day. Bulk CSV onboarding reduced manual ops effort.
High Risk
User no-shows stranding restaurants
Explicit no-show handling built into both the restaurant portal and Engine Room. Auto-mark at end-of-day for uncollected orders. Clear refund policy defined - no refund for no-show, clearly disclosed as disclaimer at checkout.
Medium Risk
Refund complexity post-payment
Pre-payment creates refund obligation on cancellation. Mitigated by auto-escrow for Pay/BNPL, and daily manual refund sheet process for digital payments. Every cancellation scenario mapped to a defined refund path before launch.
Medium Risk
Restaurant operational confusion
Separate pickup panel in restaurant portal, clear Pickup identifier on orders, and user photo/name/token ID displayed for handover certainty. Restaurant training mandatory before activation.
Medium Risk
Wrong/cold food disputes
Unlike delivery, there's no rider to mediate. CX SOP defined for missing/wrong/cold food claims. KAM monitoring preparation time compliance weekly, with removal criteria for poor performers.
Low Risk
Cache lag on enable/disable
5-minute cache propagation time acknowledged and accepted. Documented in PRD as a known system behaviour - ops team briefed not to expect instant visibility changes.
12 - Lessons & Reflections
What this product taught me
01
The hardest work was the other side of the marketplace
User-facing features are the visible 20% of a marketplace product. The 80% is the restaurant and ops tooling. Building the pickup panel, the enable/disable controls, the handover flow, the no-show process, and the CX SOPs took as much thought as the entire user experience. A pickup product that launched without this layer would have failed within weeks regardless of user adoption.
02
Prerequisite dependencies are a feature, not a constraint
Making RFD a hard prerequisite for pickup eligibility was initially seen as a limiter. In practice, it was the most important quality gate in the product. RFD restaurants had already proven reliability - linking pickup to that prerequisite meant the launch restaurant list started operationally validated, not optimistically assumed.
03
Notifications are a product, not a feature
In delivery, the rider creates natural progress signals. In pickup, notifications carry the entire behavioural load of getting the user to the restaurant at the right time. The 50%/100% prep-time notification pattern required careful tuning - too early and users arrive cold, too late and the food sits. Designing this as a system with explicit trigger logic, not ad-hoc push messages, was the right call.
04
Phase 2 scope protection prevented scope creep
Scheduled pickup, pickup-specific discounts, and Food Web support were all stakeholder requests that were explicitly moved to Phase 2 with written rationale in the PRD. Documenting what's not in scope is as important as documenting what is. It gave the engineering team clarity and gave stakeholders a visible roadmap rather than a flat "no."
05
Token ID was the simplest solution to the hardest handover problem
Early designs explored QR codes and push-based handover confirmation. Both added friction. The Token ID - a short code displayed in the app when food is ready - solved handover identification in a way that required zero restaurant tech change, worked even with poor connectivity, and matched existing restaurant counter behaviour. The simplest solution was the right one.