What Swiggy Does

Swiggy is a food delivery app. People order food and get it delivered to their door.

The User

This case study is about the person ordering, not the delivery partner or the restaurant.

The Problem

Across multiple review sources, including a dated July 2026 review, a clear pattern shows up:

• Orders arrive incomplete, damaged, or spilled. Full payment is already collected before the rider leaves.
• Support is chatbot-first. The bot's standard reply is "unable to validate your claim," and the ticket closes.
• When Swiggy does concede something, it's often store credit, not a refund. One documented case: a customer was offered ₹50 credit for a ₹920 order that arrived spilled, cold, and incomplete.
• Multiple reviewers separately describe support agents copy-pasting the same script with no real resolution.

This doesn't just cost Swiggy the price of one order. It shapes how a customer decides where to order from next time a bad resolution experience is what a customer remembers, not the food. That link to future ordering behavior is a reasonable hypothesis based on the pattern above, not something I have churn data to confirm.

The Real Tension

This isn't "the app is buggy." It's a business trying to do two things that pull against each other: minimizing support cost and protecting user trust. A chatbot that auto-closes claims is cheap. It's also the exact moment a customer decides whether they trust the platform again.

The Fix

If a customer opens more than one ticket on the same order, escalate it to a human, automatically, without requiring the customer to ask for a human explicitly.

The trade-off: escalating to a human is slower and costs more per ticket than letting the bot resolve it. That's a real cost, not a free win . The fix only makes sense if the trust it protects is worth more than the support cost it adds.

How I'd Measure It

• Outcome metric: repeat-order rate within 14 days of a resolved refund claim. This is the number that proves trust actually came back, not just that a ticket got closed. It's directly pulled from order history, not a survey score.
• Leading indicator (week one): reopen rate of escalated tickets. This proves the mechanism itself works, before there's enough time to see repeat-order data move. If escalated tickets keep reopening, the fix isn't actually resolving anything, it's just adding a slower step in front of the same failure.

The outcome metric answers "did trust come back." The leading indicator answers "does the fix even work." Both are needed, they aren't interchangeable.