ORRA Fine Jewellery 0→1→Scale
Taking two savings schemes off
paper, across 90+ stores
From paper passbooks and Excel to a mobile app and a staff web platform.
A 30-second overview
From an offline savings process to a product
I built the digital scheme management product from zero for ORRA, starting with the core of it: enrolment, payments, scheme management and digital passbooks.
The first version ran into data and reliability problems, so we stopped adding features and fixed what was underneath. Once that held, we built out Group Payments, a new payment gateway and Refer & Earn.
Over two years it went from replacing a paper process to carrying a real share of the business.
Impact
Customers pay for ten months before they get anything back
ORRA is one of India’s most recognised premium diamond brands, with more than 90 stores across India. Two savings schemes, GIS and IIS. Customers pay a fixed instalment for ten months, redeemed in month eleven with an accrued benefit on top. The business puts the two schemes at roughly 30% of revenue.
Customers enrolled and made payments through stores, while store teams managed the process using a combination of payment receipts, physical passbooks, payments marked off by hand, and the existing internal systems.
The business wanted to bring this established savings journey into a digital product.
The whole process was manual
The paper system worked, and it had for years. But nothing in it was automatic. Every step needed someone to do it by hand. And each scheme came with its own booklet, so a customer with four schemes carried four booklets and four sets of dates.
- Customer Checking savings meant a booklet or a phone call The numbers existed. But to see what you’d paid or what was due, you had to find your booklet or ask a staff member.
- Customer Paying meant going to the store Or waiting for a staff member to send you a payment link. There was no way to pay by yourself.
- Store staff Hours a day went on chasing payments Every month they worked a call list across 90+ stores. Staff said it took 2–3 hours a day, about a third of a shift. That’s their estimate, not a measured number.
- Area & regional managers No live view of what was owed To see what was due, they pulled numbers from Excel, one store at a time. Nobody recorded who had been called, or what was said.
People already trusted the paper booklet. The app had to earn that trust.
Putting the record on a screen was the easy half. The app also had to let customers pay in it, take the call list off the staff, give managers a live view, and get more people to finish all ten months. That last one is what makes the money, and it’s the one I never measured properly.
Product Owner · Sole Product Designer
- I was the only designer on this, and I owned the product too: research, strategy, design, and roadmap.
- I took the product 0→1 and through scale, fixing what broke and iterating release after release.
- I worked with four engineers and a QA, and with ORRA’s IT team on the Microsoft Dynamics 365 (MD365) integration.
- I ran the research myself across six stores in three cities, and trained store staff and managers.
- I partnered closely with the CTO, Head of Retail and Head of Consumer Finance to shape the roadmap.
What the research turned up
I spent time in the stores, with customers, and with the staff who ran the process, to see how it actually worked rather than how it was meant to.
- 6Stores visited, across 3 cities
- 18+Customer interviews, single and multi-scheme holders
- 12+Stakeholder interviews, managers, finance, IT, store and sales staff
- 5+Testers per feature, before each launch
- 15–20Managers on the dashboard, tested and trained
- 01 A phone call was the only reminder Nothing else prompted anyone. So the reminders had to take the place of that call, rather than telling staff to make it.
- 02 Staff had built their own system in Excel The official one existed and everyone worked around it. So the dashboard was built around what staff actually did.
- 03 Every scheme detail already exists in MD365 Nothing was missing. The job was getting data that already existed in front of the people who needed it.
What we shipped, and what broke after each release
- 01First release, and the data underneath it71.9% of payments getting through
- 02Changing the payment company71.9% → 82%
- 03Group Payments, and why it underperformed0.2% of volume
- 04Changing what the referral reward was worth4.1% → 45.2%
- 05Moving a thirty-second fix to the right person2–3 days → under 2 min
Three features people could see, and four data flows behind them
In 2024 we launched three things: signing up, a digital passbook, and paying in the app. All three ran on MD365, the system that holds ORRA’s real records.
- EnrolmentCustomer enrols at the counter. The scheme has to appear in their app.
- Payment historyEverything already paid, including at the store, has to show in the passbook.
- Due datesWhat’s owed, and when, has to match what the store thinks.
- Payments made in the appHas to write straight back to the system of record.
For some customers the app was showing the wrong thing
For a few customers the app was showing half the data. Some payments were not reflecting. Whole schemes were not appearing at all. The cause was a data problem in MD365, which is the only source of truth for the app and where all the scheme data comes from.
- Plans disappeared until a record refreshed.
- The passbook did not match the paper booklet.
- The payment system was failing about one in four attempts.
- Plenty of customers had more than one ID.
All of it added up to the same thing: the app could not tell a customer the truth about their own money.
We fixed the data with ORRA’s IT team straight away. Until that landed, we sorted the accounts people had escalated by hand, from the backend.
We assumed one customer had one ID. Plenty had more
We assumed one customer, one ID. After launch we found plenty of people had more than one, with schemes split across them. So a customer could open the app, see one scheme, and be sure the rest were gone.
Solution
I built a customer ID selection step. On first sign-up or login the app asks which ID to use, and explains how to change it later. The same control sits in the passbook, so a customer never has to go into their profile to see a scheme held under their other ID.
After the data fix and the customer ID picker
After the data was fixed and multiple customer IDs were in, customers started paying. Monthly digital collection went up from less than ₹1 lac a month, and more passbooks were being managed in the app.
One in four payments was failing, and customers were complaining
Some failures debited the customer first. ₹10,000 leaves your account, and then the app says the payment failed. To the customer that is not a technical fault, it is a reason to stop trusting the app with their money. Analytics, support tickets and the area business managers were all saying the same thing. The causes were checkout UX, load time and payment coverage. None of them were mine to fix. The checkout belonged to the vendor.
I asked to switch the payment company
Finance team said no twice. Higher per-transaction charges, and an incumbent already across all stores.
So I stopped arguing experience, because experience wasn’t the objection. Started showing the proof.
- 01Put a price on the failuresHow much money we lost every month, using a number finance already trusted.
- 02Measured load times on bothSide by side, same conditions.
- 03Showed them one already runningA product where I’d already shipped the alternative, so they could see it rather than take my word.
- 04Then solved the actual blockerNegotiated volume-tiered pricing. At projected volume the higher headline rate stopped being the higher real cost.
Customers with several schemes were going back to the store
Three separate places told us the same thing. Customers holding three to five schemes were going back to the counter. Paying for each scheme meant repeating the same four-step flow four times over, which was more effort than walking into a store.
- “I have 4 schemes. Paying each one separately every month is exhausting.”Customer
- “Customers say it’s easier to pay at the store counter than 4 times in the app.”Store staff
- “We’re losing digital adoption for our best customers — the ones with the most schemes.”Regional business manager
Group Payments
All scheme dues in one place. Review, unselect, and pay everything in a single transaction, however many schemes a customer holds.
- No. of due payments in the titleCount shown upfront, so customers know what they are walking into before scrolling.
- Individual scheme controlEvery payment can be ticked or unticked, so customers choose exactly what they pay this month.
- Due urgency badge“Due in 109 days” in soft amber. Enough to register that the clock is running, not enough to worry anyone.
- Total amount on the pay button“You’re paying 14 due payments ₹65,000” updates as items are deselected.
Group payment adoption
Adoption stayed low. The people using it were smaller-ticket customers, not the multi-scheme holders it was built for.
Three people describing a problem tells you it’s real. It doesn’t tell you how many people have it.
Changing what the referral reward was worth
Version 1 · initial launch
Anyone already in a savings plan could refer a friend into either plan. If the friend joined, both of them got reward points worth 10% of the monthly plan value, paid straight away.
Over four months it produced 416 referrals and 17 sign-ups. People were referring. Their friends just weren’t joining.
I went back and asked customers why.
- The reward felt small at enrolment
- The redemption felt pointless
- Effort didn’t match the reward
The reward was sized like a thank-you. What we were asking for was a ten-month commitment.
Restructuring
Rewarding the finish instead of the sign-up
I ran a session with the executive team and the finance lead.
The business’s CAC was ~₹10,000
So the reward could be worth a full monthly instalment, far bigger than before, as long as it only unlocked once both people had finished all ten months. The numbers still worked. The reward finally felt worth having, and the business only paid for customers who actually stayed.
Points now build up month by month as each payment is made. Both sides only keep them if both finish.
Impact
Post-launch · a support pattern worth fixing
People were referring when they could not earn anything
After V2 launched, the same thing kept coming up in support tickets. People without an active GIS scheme were trying to refer, then asking staff where their points had gone.
Eligibility was mentioned in the FAQs and the referral walkthrough, but customers only needed that at the moment they acted, not before.
Solution
Checking eligibility before the customer taps Invite
- A dead end became a sign-up.‘Enrol Now & Refer’ turned a frustrated ineligible customer into a new scheme enrolment.
- Fewer tickets about eligibility.Far fewer people were confused about who could refer, once the check ran before the tap.
One bug was causing a third of all support calls
Customers with active plans would log in and see nothing. It was a data delay, but to them it looked like my savings have disappeared.
It happened to 4 to 8 people a week, out of 12 to 15 support tickets in total. One bug, causing a third to a half of everything.
- 01Customer calls the store
- 02Staff raise an IT ticket
- 03IT assign to engineering
- 04Engineer refreshes the record (30 seconds of work)
- 05Customer notified
I put the same operation on every row of the staff dashboard: search by mobile, tap Refresh. Five steps become two. The same thirty seconds, moved to the person already standing in front of the customer.
- 01Customer calls the store
- 02Staff search by mobile and Fetch Data
Not every problem needs code. Sometimes design just moves the button to the right person.