Handle merchant complaint about excessive demand

Handle a Merchant Complaint About Excessive Demand

A merchant complains that DoorDash is sending more demand than their store can handle. They say the extra order volume is hurting operations, increasing wait times, and creating a poor experience for customers and couriers.

You are the Data Scientist asked to help product and operations respond.

Constraints & Assumptions

• Treat the complaint as a signal to investigate, not as proof of the full root cause.
• Consider the interests of merchants, customers, dashers, and DoorDash.
• Propose both short-term mitigations and longer-term product or model improvements.
• Include metrics that show whether the response helped without simply suppressing growth.

Clarifying Questions to Ask

• Is this one merchant, a chain, a cuisine segment, or a broader market pattern?
• Which experience is failing: prep time, order accuracy, cancellations, wait time, ratings, or support contacts?
• Did recent promotions, ranking changes, dispatch changes, or menu changes increase demand?
• Does the merchant have tooling to pause, throttle, adjust prep time, or limit menu items?

What a Strong Answer Covers

• Validate the complaint with data: order volume, prep time, dasher wait, cancellation rate, late deliveries, refunds, ratings, and support tickets before and after the demand spike.
• Segment by merchant, time of day, menu item, order size, promotion, and channel.
• Diagnose whether the root cause is demand surge, inaccurate prep-time prediction, merchant staffing, menu complexity, batching, or dispatch timing.
• Propose interventions such as throttling, dynamic prep times, capacity controls, temporary promotion changes, merchant alerts, menu simplification, and operational playbooks.
• Evaluate impact using merchant health, customer experience, dasher wait, fulfilled orders, revenue, and long-term retention.
• Communicate trade-offs transparently to cross-functional stakeholders.

Follow-up Questions

• How would you decide whether to reduce the merchant's exposure in ranking?
• What metric would detect whether throttling went too far?
• How would you handle this differently for a strategic enterprise merchant?
• What product feature would prevent similar complaints in the future?

Solution

Solution Alignment Notes

Treat the merchant complaint as a data signal to investigate. Balance merchant capacity, customer reliability, dasher wait time, and marketplace growth when recommending mitigations.

---

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.