Why Half of New Simpl's SPaD Users Didn't Know They'd Chosen a Credit Product

The Market Simpl's SPaD Was Built For

Indian e-commerce has a structural problem no payment innovation has solved: buyers don't trust merchants enough to pay before they inspect. ET Prime Research puts roughly 60–65% of all Indian e-commerce orders on Cash on Delivery.¹ UPI is available almost everywhere. People still choose COD because it lets them hold the money until the box is in their hands. It's a trust mechanism wearing the costume of a payment method.

In Tier-2 and Tier-3 cities the gap widens. Shiprocket data has 90% of transactions there running on COD.³ Edgistify's FY24 breakdown puts the cost of a single return-to-origin at over ₹13,000 once you add forward freight, return freight, packaging, and handling.⁴ A brand doing 5,000 COD orders a month at a 25% RTO rate burns more than ₹1.6 crore in logistics before it has counted a rupee of inventory or labour.

Simpl's Pay After Delivery (SPaD), launched in 2023, was the most honest answer anyone had built to this. It didn't try to talk the committed COD buyer into paying upfront. It underwrote the order instead. Simpl pays the merchant on shipment, and the buyer settles with Simpl after delivery, through the app. The low-intent orders that drive returns tend to self-select out at checkout, because the buyer now knows they're taking on credit rather than COD.

The hypothesis was sound. The execution had a problem nobody had measured.

What I Inherited

The delinquency data looked simple and wasn't.

The merchant-level variance made the question sharper. Limeroad's new-user delinquency ran at 48.53%. Zoop's ran at 14.01%. Same product, same comms stack, and a 4× difference in whether people paid. Variance that wide doesn't come from intent. It comes from whether the user understood what they'd signed up for.

My brief was narrow: find out why, and propose fixes ranked by impact.

Research Design

I designed a 4-cohort interview structure and wrote the SOP. Before each call, I cross-referenced CRM history for transaction context, merchant, and delinquency status. The goal was to walk in with a falsifiable hypothesis, not just an open conversation.

The Finding That Reframed Everything

The first cohort I called, new users who hadn't paid, kept saying the same thing.

"I did not even know I had selected SPaD. I thought it was COD and I paid the delivery agent. They are not supposed to accept payment, you only pay through the Simpl app after the bill is generated."

This wasn't an edge case. Across 97 completed calls, 49% of users had no idea they'd chosen a credit product. They thought SPaD was a flavour of Cash on Delivery, and the checkout did nothing to correct them. It sits in the same section as COD, asks for no money upfront, and the delivery agent shows up expecting nothing.

In Tier-2 and Tier-3 cities, where a lot of users had little prior exposure to BNPL, the product quietly demanded three things at once. The user had to understand SPaD wasn't COD, know to install the Simpl app, and then remember a billing cycle they'd never encountered before. None of that was guaranteed, and the comms stack wasn't built to make it happen.

The Five Problem Themes

Call findings clustered into five categories with measurable reach across the SPaD user base:

Problems 1 and 2 together hit 53.9% of the user base, and both are fixable with comms and UX. Problem 3 is a separate animal: repeat users who get Simpl but don't see why SPaD differs from Pay Later. Problem 5, the one the original hypothesis treated as the main event, turned out to be the smallest.

The Communication Gap

I could see the structural problem in the touchpoint audit before I'd finished a single call.

The only window where you can change behaviour sits between order placement and delivery, while the transaction is fresh and before the user has met the delivery agent. SPaD's comms fired after that window had already shut. For someone who thought they were on COD, the first message that actually explained anything landed after they'd handed cash to the delivery agent.

Solution Prioritisation

I scored 9 solutions across reach, impact, and effort. The scoring methodology treated reach as the percentage of SPaD users affected by the root problem each solution addressed.

Solution 1 · Educational WhatsApp at order placement

A media-rich WhatsApp message that fires at the charge call, when the order is placed, not at delivery. New users get the full version: this is Simpl, this is how SPaD works, do not pay the delivery agent. Repeat users get a lighter version that reinforces the value prop. Zoop already had this set up. The work was extending it to every merchant and pulling the trigger 3–4 days earlier in the journey.

Solution 2 · Day 2 and Day 4 SMS

KenResearch logistics data puts average delivery at 3–4 days. A Day 2 SMS keeps SPaD top of mind while the order is still in transit: "Your order is on the way, no need to pay the delivery person." Day 4 fires only if the claim call hasn't happened yet. It mirrors the Pay Later cadence that was already live and working.

Solution 3 · Linking confirmation success page

The OTP linking screen did carry SPaD information, but nobody read it. They were busy typing the OTP. The success page right after confirmation is the real moment of captured attention. I proposed redesigning it to say the three things that matter: you chose SPaD, not COD; you pay through the Simpl app; here are the app store links. There was a tradeoff to manage. Adding a CTA could drag down completion, so I proposed a soft informational version first, with no second confirmation action.

Solution 4 · App install nudge cadence

SPaD users got a single Day 0 app-download prompt, sent post-delivery. Pay Later users got a reminder every two days until Day 10. Matching that cadence for SPaD, triggered from the charge call, closed the recall gap with no product change at all.

What I Decided Not to Prioritise

The return-initiation API made the sheet too. When a return API isn't configured for an SPaD merchant, the user gets billed for something they couldn't send back. That's a real delinquency driver for the 12.4% order-issues cohort. But at an impact of 0.1 and effort of 1.0 it ranked dead last, so I flagged it for the merchant-integrations team rather than this sprint.

What I'd Do Differently

Two things I'd change if I ran this again.

First, I'd instrument the COD confusion rate from day one. It took four weeks of calls to surface the 49% figure. A single survey intercept on the linking confirmation screen, asking "What payment method did you just select?" with three options, would have produced that number in week one and saved a full sprint of prioritisation.

Second, the repeat-delinquent cohort gave me the weakest signal in the dataset: 78 in the sample, only 16 picked up. Seven of those sixteen cited an actual inability to pay rather than confusion. That group needs a completely different fix, underwriting calibration and limit-setting, not comms. I should have over-sampled them precisely because their solution diverges so far from the confusion cohort. Scoring them on the same priority sheet was the methodological hole in this project.

The comms fixes go after the 78%+ of new-user delinquency that traces back to confusion and recall failure. They do nothing for genuine financial hardship or intent. Those are harder, they belong to a different team, and treating them as the same problem is exactly how you end up shipping the wrong solution.

Results shared by my manager post-internship.

Footnotes

1. ET Prime Research (2024), cited in Upstox Originals, November 2025. https://upstox.com/news/upstox-originals/investing/is-cash-on-delivery-quietly-costing-you-more/article-184260/ ↩

2. Unicommerce Online Shopping Trends CY2024. https://smestreet.in/infocus/unicommerce-reports-2024-online-shopping-trends-in-india-8621424 ↩

3. Sacra, Shiprocket revenue and business analysis, 2024. https://sacra.com/c/shiprocket/ ↩

4. Edgistify, RTO Costs Breakdown for Indian E-commerce. https://www.edgistify.com/resources/blogs/rto-costs-breakdown-india ↩