How Do You Know If a Fulfilment Partner's SLA Is Actually Good?
Every fulfilment partner you evaluate will show you a strong on-time delivery number, often 97% or higher. Almost none of them will walk you through how that number is measured, and that is exactly where the risk sits. Two partners can quote the same headline SLA and mean two different things by it, and the gap between those definitions is what shows up later as missed delivery windows, a rising RTO rate, and a customer support team fielding complaints your dashboard says shouldn't exist.
This is not a legal breakdown of contract clauses. It is the operational lens to bring into a vendor call before the contract even reaches your legal team, so you are asking the right questions the first time, not renegotiating six months into a live partnership.
The SLA percentage on the slide is not the SLA you're signing
Most fulfilment partners pitching D2C fulfilment and same-day delivery in India will lead with a blended, company-wide on-time percentage. That number is real, but it is also the least useful figure in the deck, because it tells you nothing about performance in your specific cities, your specific order profile, or your specific peak periods.
A partner running 30-minute, 60-minute, and same-day tiers across multiple cities can post a strong blended average while one city or one dark store is quietly underperforming. If your brand's order volume is concentrated in that city, the blended number is actively misleading you. The fix is simple to ask for and rarely offered upfront: request the on-time percentage broken out by city and by delivery tier, not just the company average.
Turnaround time definitions hide where the real risk sits
Turnaround time (TAT) sounds like a fixed, objective number. In practice, it depends on where the clock starts. Some partners measure from the moment a rider is dispatched from the dark store. Others measure from the moment the customer's order is confirmed. The gap between those two start points, order confirmation to dispatch, is internal processing time, and it can run anywhere from a few minutes to over half an hour depending on how the partner has built its dark store and picking workflow.
A partner quoting a 60-minute SLA measured from dispatch, not confirmation, can still deliver a customer experience that feels like 90 minutes. This is precisely the kind of gap that shows up downstream as failed deliveries and rising returns to origin, which is why recovering a failed delivery before it becomes an RTO starts with getting the TAT definition right at the contract stage, not after the first spike in exceptions.
What a penalty clause is actually meant to protect, and where it's usually weakened
A penalty clause exists to make the fulfilment partner's incentives match yours. In practice, most standard clauses are written with enough grace band and enough measurement lag that they rarely bind. Here's the pattern to check for across the metrics that matter most, framed as vendor-favorable versus founder-favorable definitions:
| SLA metric | Vendor-favorable definition | Founder-favorable definition | What to ask for |
| On-time delivery % | Clock starts at dispatch, not at order confirmation. Excludes first-attempt failures. | Clock starts at order confirmation. Includes every attempt, not just the ones that succeeded. | A written definition of the start and end point of the clock, not just the percentage. |
| RTO / NDR rate | Reported as a lagging monthly average across all cities pooled together. | Reported city-wise and dark-store-wise, since a national average hides local failure. | Segment-level reporting, not a single blended number. |
| Penalty trigger | Penalty kicks in only after a large, sustained breach (for example, a full month below threshold). | Penalty scales with severity and kicks in from the first missed threshold, not after a grace period built to never bind. | The exact threshold, the measurement window, and the payout mechanism in writing. |
| Escalation response time | Undefined, or bundled into general 'support' language. | A specific response time (for example, under 2 hours) for SLA-breach escalations, separate from routine support tickets. | A named escalation path and a committed response window. |
| Reporting cadence | Available on request, or only inside an annual business review. | A live dashboard or a weekly report you can act on before the damage compounds. | Real-time or weekly visibility, not a quarterly PDF. |
None of the above is legal interpretation of any specific contract clause. It is an operational framework to bring into the conversation, with your own commercial or legal counsel making the final call on language.
The escalation SLA nobody asks about until day 47
Most vendor evaluations focus entirely on the steady-state number: the monthly on-time percentage, the RTO rate, the blended average. Almost no one asks what happens when a specific order is already at risk, mid-delivery, during a flash sale or a festival spike. That is the escalation SLA, and it is the clause that actually protects your improve NPS goals in the moments that matter most, not the monthly average.
A fulfilment partner with a strong headline number but no defined escalation response time can still let individual at-risk orders pile up between reporting cycles. This is the gap most founders discover only after their first high-volume event, which is also where the metrics an ops lead should actually be tracking become a live operating tool instead of a monthly report card.
The checklist to bring into your next vendor call
Bring these questions into the room before the contract is drafted, not after:
- Where does the turnaround time clock start: order confirmation, pick, or dispatch?
- Is the on-time percentage reported blended, or broken out by city and delivery tier?
- What counts as a delivery attempt, and are failed first attempts included in the denominator?
- What is the exact penalty trigger threshold, and what is the measurement window (weekly or monthly)?
- Is there a separate, faster response-time commitment for escalations versus routine support tickets?
- How often will SLA performance be shared, and is it a live dashboard or a periodic report?
- Are the riders and delivery partners full-time, or third-party gig riders rotated across multiple platforms?
That last question matters more than it looks. A fulfilment partner staffing its own full-time delivery workforce has a direct line of accountability for SLA performance and last-mile delivery consistency. A partner leaning on rotating gig riders shared across platforms has a much weaker lever to actually fix a slipping SLA, because the rider on your order today may be someone else's tomorrow.
Where Zippee fits into this
Zippee is built around the questions above, not around a single headline percentage. Delivery is run through a full-time employed rider network, not gig workers rotated across platforms, which is what makes an escalation SLA enforceable rather than aspirational. SLA performance is tracked at the dark store and city level, with reporting cadence built for weekly operating reviews rather than a quarterly business review slide.
This is also why Zippee is built as infrastructure for a brand's own D2C channel, powering hyperlocal delivery and RTO reduction for 100+ D2C brands and marketplaces across 21+ cities, rather than as a generic courier layered on top of someone else's dark store network. The SLA a brand signs is only as strong as the operating model behind it, and that operating model is the thing worth stress-testing before the contract, not after.
If you're ready to turn your fulfillment into a competitive advantage, join our waitlist.
.png&w=256&q=75)
.png&w=256&q=75)
.png&w=256&q=75)
.jpg&w=256&q=75)
.jpg&w=256&q=75)