Handle merchant complaint about excessive demand
Company: DoorDash
Role: Data Scientist
Category: Behavioral & Leadership
Difficulty: Medium
Interview Round: Onsite
## Scenario
A merchant partner complains that DoorDash is sending **more orders/traffic than they can handle**, leading to operational strain and a poor in-store experience.
## Task
As a Data Scientist (partnering with Product/Ops), explain how you would:
1. Triage and diagnose whether the complaint is valid using data.
2. Identify root causes (e.g., sudden demand spike, capacity limits, inaccurate prep-time settings, throttling issues).
3. Propose interventions that balance the 3-sided marketplace (consumers, dashers, merchants).
4. Define how you would monitor impact and avoid unintended consequences.
Quick Answer: This question evaluates a Data Scientist's competency in data-driven operational diagnostics, cross-functional collaboration with product and operations, and marketplace optimization in a three-sided delivery marketplace, and is categorized under Behavioral & Leadership.
Solution
### 1) Triage: verify the issue and quantify impact
Start by aligning on what “too much traffic” means operationally:
- Max orders/hour the kitchen can handle
- Staffing level by daypart
- Whether the pain is from *order volume*, *order timing* (spikes), or *order complexity*
Pull a before/after view (e.g., last 2 weeks vs prior 4 weeks) for that merchant (and comparable merchants):
- Orders/hour by daypart; peakiness (P95 orders/hour)
- Prep time (P50/P90) and variance
- Merchant cancellation rate and reason codes
- Late orders, refunds, missing items
- Dasher wait time at store
If merchant KPIs degraded at the same time volume spiked, the complaint is likely valid.
### 2) Diagnose root causes (common patterns)
**A. Demand spike drivers**
- Promotions, pricing changes, featured placement, search ranking changes
- Local events or competitor outage
**B. Capacity mismatch**
- Merchant hours/availability inaccurate (store marked open while understaffed)
- Menu item availability not updated (out-of-stock leading to substitutions/delays)
**C. Incorrect operational parameters**
- Prep-time settings too low → dashers arrive early and congestion builds
- No effective throttling / order caps during peak
**D. Marketplace spillovers**
- Delivery radius too large bringing in extra demand
- Reassignment/batching causing bursty arrivals at the merchant
### 3) Interventions (balance all sides)
Pick the least invasive intervention that restores service quality.
**Merchant-protecting controls**
- **Order throttling / caps**: max orders per 15 minutes during peak.
- **Busy mode** / dynamic prep times based on real-time backlog.
- **Temporary pause** or reduced delivery radius during staffing shortages.
- Improve menu management (auto-86 items when out-of-stock signals appear).
**Consumer experience safeguards**
- Update quoted ETAs and availability transparently instead of accepting orders that will fail.
- If throttling reduces supply, ensure ranking/search reflects availability to reduce frustration.
**Dasher experience safeguards**
- If the merchant is congested, reduce early arrivals by delaying dispatch or improving ready-time prediction.
**Operational partnership**
- For top merchants, offer ops playbooks: staffing guidance for expected demand, peak-hour scheduling.
### 4) Measurement and monitoring
**Primary success outcomes (merchant health):**
- Merchant cancellation rate ↓
- Prep time P90 ↓ (or stabilizes)
- Dasher wait time ↓
- Merchant satisfaction / complaint volume ↓
**Guardrails:**
- Consumer conversion and completion rate (don’t over-throttle)
- On-time delivery and refund rate
- Merchant revenue (avoid unnecessary demand suppression)
**Evaluation design:**
- If rolling out throttling logic, do merchant-level A/B (or stepped-wedge rollout) because interference is localized.
- Monitor for demand shifting to nearby merchants (good) vs overall demand loss (bad).
### 5) Recommendation
Treat this as a service-quality risk: accept fewer orders but deliver them reliably.
Implement short-term throttles and correct prep-time/availability settings immediately, while building a longer-term dynamic capacity model (predict max sustainable order rate by daypart) to prevent recurrence.