Case study · Internship · ERP
Sampoorna
A store’s restock list used to take three weeks to pass through six pairs of hands. I designed Falca’s purchase cycle so all six roles work on one live indent, from request to invoice.
one list, six people, zero WhatsApp forwards 🌾
One restock list passed through six people over three weeks, and everyone edited a different copy.
I designed Sampoorna’s purchase cycle, indent to invoice, for all six roles: the research, the flows and every web and mobile screen. The team was a PM, an engineer and me.
Not live yet. Four flows, 16 web screens and 10 mobile screens, handed off to developers at the end of my internship.
Six interviews and three days at HQ found the same three breakdowns in every role: stock nobody could see, approvals with no record, and finance on paper.
Designs for four flows on web and mobile, with the developers.
Nothing yet. It wasn’t live while I was there.
A ten-day indent cycle, down from three weeks. This is a design target.
Short on time? The summary above is the whole story.
01 · Context
One product the whole chain can use
Sampoorna is Falca’s multi-role ERP for 30 shops. My part was its purchase cycle: how an indent moves from store to supplier to finance, for six distinct user types, designed from the first interview to developer handoff. It replaces paper registers, WhatsApp approvals and Tally exports with one connected flow.
The goal was to design one product the whole chain could use without retraining the whole chain: the same list, the same patterns and the same live data for a store manager on a phone and a finance officer at HQ.
02 · Problem
An indent nobody owns
Sampoorna’s purchase cycle travels through six people before a single item reaches the shelf. At every handoff, a WhatsApp message, a Tally entry or a handwritten register changes a number.
Indents lived on WhatsApp.
A store manager typed a list into chat. The territory manager replied with changes. Someone read it wrong, someone missed the reply. By Friday, the indent on the purchase manager’s screen was a different document to the one in the store manager’s head.
Approvals happened on phone calls.
A regional manager said yes over the phone. No timestamp, no record of what was approved, at what quantity, or why. Two months later an auditor asked who had signed off on a ₹40,000 order. Nobody could say for certain.
Every Tuesday, a blank Excel sheet.
Thirty stores, two hundred SKUs. One purchase manager pulled each store’s indent from WhatsApp, grouped the same SKU across stores, split it by supplier and checked rate cards. Then a store sent a revised list at 11am and it all started over.
It compounds fast. A purchase manager ordering on stale figures overstocks one store and understocks another. A regional manager approves something that has already changed. An auditor reconciles numbers that were never in sync to begin with.
How might we give each of the six roles exactly the information they need, at the right moment, so one indent moves cleanly from store to supplier to shelf without losing accuracy along the way?
03 · Research
Two weeks before opening Figma
Six conversations with real users across every role, and three days at HQ watching a purchase manager reconcile 30 stores in one Excel sheet. Each conversation followed one structure: walk me through how you work, where it slows down, what you wish was different.
Store managers, territory managers, a purchase manager consolidating thirty stores every Tuesday, and a finance officer whose only system was a notebook.
Watching the purchase manager pull indents from WhatsApp and rebuild them in Excel, end to end.
Every quote on a card, clustered until the themes held. By the sixth interview, nothing new was surfacing.
Affinity board · real quotes
Data visibility
Nobody designed for this gap on purpose. Paper has no send button, so the store manager’s only audience is the page in front of them.
What happens after you count stock?
“I write it down. Nobody ever asks to see it.”
the root cause of it allDoes anyone check it later?
“Maybe month end. By then everything changed.”
How do you know when something expires?
“I find out when I see it on the shelf.”
reactive, never proactiveApproval chain
Approval was a yes or no moment, not a decision with context. Nobody checked stock first, because the tool to check it was three apps away.
How do you approve a purchase request?
“Someone sends a message. I say yes or no.”
Do you check current stock first?
“I can’t. I just approve.”
four people, four versions of the same numberTwo months later, who approved the ₹40,000 order?
“Nobody could say for certain.”
this quote sold the audit trail featureFinance
Finance was never given a system to inherit, so the notebook became permanent by default. Nobody chose it; it just never got replaced.
Where do you track daily collections?
“My notebook. Nothing is in any system.”
How long has this notebook been the system?
“Since before I joined. Three years.”
three years, nobody flagged thisWhen numbers don’t match?
“I spend a whole day reconciling.”
this became the daily ledger featureThe same three problems came up independently, across different roles, in different cities. That consistency was the finding.
04 · Users
Three worlds, one system
The chain runs across three different worlds. The store operates on the ground: raising indents, receiving goods, logging stock. The region manages what flows between stores and procurement. HQ is where money moves, orders are placed and the audit trail lives. Same system, three completely different sets of problems to solve.
Retail operations platform
Store operations
- Store managerRaises indents, confirms GRNs, manages daily stock and onboards staff.
- Store staffRecords sales on the POS, logs stock movements and flags issues to the manager.
Chain management
- Territory managerReviews and curates indents across multiple stores before approval.
- Regional managerGives final approval on indents and oversees territory performance and budgets.
Procurement and finance
- Purchase managerConsolidates indents, raises supplier POs, validates invoices and GRNs.
- Finance officerTracks collections, manages invoices and handles vendor payments.
05 · Synthesis
How each role connects to the system
Every sticky is a job a role does in the chain. The arrows show where one person’s output becomes another person’s input, and where the handoffs used to break.
06 · Flow
One request, seven handoffs
One request. Seven handoffs. From the store manager raising the indent to finance closing the payment, every step tracked, every action recorded, every person accountable.
07 · PO model
One order, many deliveries
Suppliers rarely deliver an entire purchase order in one trip. A 47-SKU order might arrive across three separate deliveries over two weeks, each with its own invoice, its own GRN and its own chance of a shortage. The first model assumed a 1:1 relationship: one PO, one invoice, one payment. It was simpler to design, but it broke the moment a real order shipped in parts.
- Easy to build and explain
- Can’t represent partial deliveries
- Forces a workaround PO per trip
- Matches how suppliers actually ship
- A shortage becomes a credit note
- More states for finance to read
A single purchase order can be fulfilled across multiple trips, and each trip generates its own invoice and GRN, sometimes with its own discrepancy that needs a credit note. Finance’s most common question: “Which invoice belongs to which PO, and did we already pay it?”
Parent POPO-880-A₹4.48 L
every invoice, GRN and credit note hangs off the parent PO, fully timestamped, fully attributed
08 · Merge
Merge the stores, or keep them separate?
Once indents are frozen, the same item often shows up across several stores at once. Combining that demand can mean better pricing and a cleaner supplier check, but it assumes every store wants the same thing on the same timeline. The real question wasn’t “what’s the optimal order size?” It was “does Store A and Store B’s request become one order of 100, or stay two?”
- One combined quantity, stronger pricing
- Assumes every store’s urgency matches
- Can’t split back once merged
- Merge when it helps, keep separate when it doesn’t
- Still one PO per supplier at the end
- One more decision in the flow
Matching items across storesFertilisers · Store A: 50, Store B: 50
Merge matching items?
NoAnalyse suppliers per store, individually
YesMerge to 100 units, analyse suppliers for the combined quantity
View supplier optionsCapacity and pricing per supplier
How to split into POs?
One supplierSingle PO, multiple items
Split by supplierMultiple POs, one per supplier
Split same itemMultiple POs for the same item, across suppliers
Forward for approval: one PO per supplier, guaranteed
09 · Screens
Four flows, one indent
The design, in the order an indent lives it: raised and submitted, reviewed and approved, merged into one purchase order, then received and checked. Pick a step to see its screen; click a screen to open it full size.
Creating and submitting an indent
I kept hearing the same thing in interviews: nobody trusted the indent they were looking at, because six versions of it existed across six phones. So I built one flow where raising, reviewing and submitting all happen against the same version, in the same place.
Reviewing and approving requests
I didn’t want to build a second, parallel version of this data just for approvers. I kept the exact same list and only changed what a person was allowed to do with it.
Merging indents into one purchase order
Thirty stores were about to become thirty tiny, inefficient orders. I built consolidation so that whatever came in, only one purchase order ever reached a given supplier.
Closing the loop: goods in, stock updated
I didn’t want a shortage or an overpayment to surface a month later, in an audit. So the GRN, the one document that proves what actually arrived, updates inventory and notifies finance the moment it’s confirmed.
10 · Mobile
Every screen, grouped by its job
Not a flat list of ten screens. Three jobs: build the indent, act on it, and stay in the loop after.
The same four-step arc as desktop, compressed for one hand: see what’s ongoing, narrow it down, add products, review before sending.
This is the same Product Details screen, reused across three points in the approval chain. Only the bottom action bar changes.
What happens around the indent, not inside it: the audit trail, updates and account access.
11 · Outcome
Handed off, with a plan to measure
I designed the full purchase cycle, indent to invoice, for web and mobile, and handed it to the development team at the end of my internship. It wasn’t live while I was there, so I haven’t measured results. The ten-day cycle is the design target, not a measured number. This is what I would track once it ships.
Three weeks before. Ten days is the target.
Share of approvals made in the app, with who and when, instead of a phone call.
One consolidated order instead of one per store.
Discrepancies flagged on receipt, not a month later in an audit.
From a whole day per mismatch to matching invoice, GRN and PO in one place.
12 · Reflection
Owning more than I expected to
I didn’t go into this internship expecting to own an ERP’s whole purchase cycle by myself. Six roles, thirty stores, replacing years of WhatsApp messages and Excel sheets was a lot more scope than I thought I’d get as an intern. I’m glad I was trusted with it.
Nobody agrees on everything upfront
Store managers, territory managers and the purchase manager all had different ideas about what mattered most on the same screen. Checking in constantly and staying flexible mattered more than getting it right on the first try.
The bigger scope taught me more
I could have focused on just the store manager’s flow and finished a lot faster. Taking on all six roles meant more complexity, but it’s also where I learned to think about a system, not just a screen.
Not every opinion carries equal weight
Some feedback came from people who’d never raise an indent or approve a purchase order themselves. Weighing that against what real users told me, and trusting my own read on the problem, was one of the harder parts.
