Back to my works Inventory Management System (IMS)
Redefining Inventory for the Real World
A purpose-built system to manage STB and accessory orders, streamline multi-level approvals, track distribution, and maintain transparent records across SMS and Accounting.
My Role
UX Research
Workflow Mapping
Collaboration
Product Design
Duration
9 months
Team
System Architect
3 Developers
Impact
Reduced approval turnaround time
Clear tracking and role-based actions
Improved audit efficiency
About the Client
TCCL is one of Tamil Nadu's largest cable TV operators, serving over 2 million subscribers across the state.
They operate on a rental model, purchasing set-top boxes (STBs) from vendors and distributing them through a vast network of local cable operators. Beyond STBs, they also procure electricals, electronics, networking equipment, and general office supplies from multiple vendors, all of which need tracking, approval, and record-keeping at scale.
From Cable to Control: A Natural Next Step
After wrapping up the Subscriber Management System (SMS) redesign, the TCCL team came back to us, but this time, they wanted less. They didn't want a huge system packed with every inventory feature under the sun. They didn't want to learn a new language just to issue a purchase order.own led to chaos. People stopped relying on the software and started doing everything manually. It was messy, stressful, and slow.
"We don't want everything. We want only what we use."
So we built a new Inventory Management System (IMS) from scratch. Designed around real workflows. Built for clarity, not complexity. Fully integrated with the systems they already trusted, SMS and Accounting.
Before I designed a single screen, I spent time understanding the language of inventory, not software inventory, but real-world, boots-on-the-ground inventory. I listened to how they raised indents, how they tracked repairs, and how they still relied on physical challans as a source of truth.
Every insight became a design opportunity.
User PersonasUnderstanding our primary users and their unique challenges in the IMS system workflow
Kumaravel
Inventory Head
Approvals were getting lost in paper work process, and half the time I wasn’t sure if a PO had even been raised.
- Reviews new purchase indents and vendor quotes
- Approves or rejects POs based on stock needs
- Maintains vendor communication for order status
- Downloads reports for monthly audits
- Confusing PO approval process across multiple managers
- Re-entering the same data at different stages
- Having to maintain parallel paper logs
- Keep every purchase traceable, from indent to payment
- Approve and track orders without chasing people
- Ensure that every action is logged and can be verified later
- Not highly technical; prefers simple, guided workflows
Meenakshi
Service ManagerI had no real-time view of where a box was once it left my desk.
- Checks new service requests from LCOs
- Validates STB warranty before assigning to technicians
- Coordinates with inventory for replacement units
- Tracks STB movement
- Service assignment involved too many clicks
- No easy way to check warranty before processing repairs
- Tracking STBs required calling multiple people for updates
- Assign service requests quickly without extra steps
- Track warranty status instantly
- Ensure service employees update the system
- Prefers guided flows and auto-fills over manual entries
It was clear that daily operations were slowed by scattered processes, unclear approval flows, and poor visibility across stock movements. These insights shaped IMS into a unified, approval-driven system with complete traceability, built to match real-world distribution workflows.
Designing Like a Human Would Use It
Just like with SMS, I didn't start with modules, I started with verbs.
That's how people actually think. So every screen was shaped around an action, not a data table.
From those verbs, five core modules naturally took shape: Product Ordering, Distribution, Reports, Service Management, and setting. Each one was designed to feel less like software and more like doing the task itself.
What Made This Hard And What Made It Work
Fragmented Ordering & Approval Process
ChallengeThe purchase flow was layered and approval-heavy. Indents are raised, vendors respond with quotes, and one vendor is selected. Then a purchase order is created and needs approval from five different people: Inventory Head, Accounts Head, CEO, CTO, and General Manager. After approval, the PO is emailed to the vendor, and only then can the bill be sent to Accounting.
And this wasn't a "click and done" process. It was a human process, with dependencies, responsibilities, and serious financial impact.
Instead of burying functionality behind menus, I made the flow visible, right inside the PO card. Every action had its own button, View PO, Send Email, Send Bill, but only became active when the previous step was completed.
So when the final manager approved a PO, the email button lit up for the inventory user. Once the vendor acknowledged, the bill button became clickable for the accounts team.
Once the indent is approved, the procurement process moves to Product Ordering.
Step 1 Raise PO: Fill in vendor details, item breakdown, and approval heads to create a Purchase Order.
Step 2 Email PO to Vendor: Send the approved PO directly to the vendor with auto-filled details and attachments.
Once the PO is approved by the heads, the Email button becomes active, a clear signal that it’s ready to be sent to the respective vendor. Clicking it opens the email page with key details and attachments already in place, so the user can focus on fine-tuning the message and sending it out quickly.
All non-essential options are tucked away, keeping the user’s attention on reviewing and sending the PO quickly.
Step 3 Send to Accounting: Push the finalized PO to the accounting system for payment processing.
With the bill sent to the Accounts team and all vendor communications securely logged, the PO process reaches its completion.
While this case study walks through the PO process in detail, all other workflows, from Indent Raising and GRN Creation to STB Distribution and Service, were designed with the same guided, step-by-step flow to keep users confident and error-free. This consistency made the entire system easy to learn and operate, no matter the task.
Making Paperwork Digital, Without Losing the Familiarity
ChallengeThe TCCL team lives and breathes documentation. Every delivery, every fault, every return happens with a challan, and they didn't want that to change. What they didn't want was confusing digital interfaces trying to "re-imagine" a system they already understood.
I leaned into the familiar forms that felt like challans, just smarter.
- Auto-filled 'From' and 'To' addresses based on dropdowns
- Challan types like fault, return, delivery, designed with minimal typing, maximum dropdowns
- Products auto-populated from previous actions (e.g. indents linked to Vendors and Products)
- Payment modes (split, EMI, full) selectable per PO
- Final forms exported as PDFs, just like their printed challans, but cleaner, faster, and always accurate
The PO form, Indent form, and GRN form, each was crafted like a guided document. Familiar, but faster. Comfortable, but complete.
Linking Everything, So Users Don't Have To
ChallengeEach step in the inventory flow relied on data from the previous step. But users shouldn't have to retype anything. They didn't want to chase serial numbers or duplicate entries.
Everything was connected behind the scenes.
- When an Indent ID is selected, the vendor, item list, and agreed price auto-fill instantly.
- When a vendor is chosen, their contact details and addresses load automatically.
- When a PO is selected in the GRN form, the full product list appears with quantities.
- The payment mode agreed upon earlier is already in place at the payment stage.
- Vendor email IDs are auto-fetched when sending the PO.
- In the delivery challan, from/to addresses and item details flow directly from LCO requests.
This made the system feel like one continuous, intelligent workflow rather than disconnected forms.
Users didn't have to think about what's next. The system quietly remembered everything for them.
Designing for Reality: Renting, Servicing, Scrapping
Beyond procurement, the real complexity came in lifecycle flows, what happens after an STB enters inventory.
STB Request from LCO
ChallengeWhen an LCO needs new STBs, they place a request through the SMS tool. The inventory team gets notified, but before taking action, they call the LCO directly, just to make sure the request is genuine.
Once confirmed, the requested units are dispatched, and both IMS and SMS stay perfectly in sync, updating the status automatically across systems.
To handle multiple daily STB requests efficiently, I split the flow into two steps: a Request Review Screen for quick verification and approval/rejection with accountability, and a Stock Transfer Screen for scanning, uploading, and linking approved STBs to the correct LCO.
Step 1 Request Review: LCO submits a product request, which can be approved or rejected by the admin.
Step 2 Approved PO Processing: Approved POs appear in a dedicated list; selecting one auto-fills requester details from the PO, the user simply chooses a warehouse, uploads the requested items, and selects the challan type.
This made the distribution process clean, controlled, and fully logged.
Designed in Loops, Not Lines
I approached the design in tight, iterative loops, not straight lines. I had weekly check-ins with stakeholders to stay aligned and gather feedback early. I shared prototypes as soon as possible so real users and teams could interact with them, not just look at pretty screens.
Every step of the way, I worked closely with both frontend and backend developers.
Refinements That Made It Even Better
Once the users started interacting with the early prototypes, the real magic began. They could finally see how the tool would work, and that helped them express what they really needed.
For example, in the Purchase Order flow, they clarified that there are only three types of payment modes: Split, Full, and EMI. Initially, I had left the payment input open-ended, but based on this, I turned it into a dropdown. Now, when a user selects the type, the system auto-calculates and displays the payment breakdown, no manual work needed.
Another key refinement came in Service Management. Originally, assigning a service employee was a two-step process. But managers pointed out they just needed to see the STB details and assign someone in one go. So I redesigned that view. Now, managers get a full snapshot of the issue, warranty info, and just one clean dropdown to assign an employee. That's it.
The Outcome
We finally have one source of truth for inventory and it doesn't feel heavy. It feels ready.
Once IMS went live, the difference was immediately felt:
- Procurement became faster, structured, and fully traceable
- Warranty management now runs automatically in the background
- Every STB has a complete, searchable life-cycle from vendor to scrap
- Integrations with SMS and Accounting eliminated redundant work
- Teams picked it up instantly, without a single training session
- It fit the way they already worked. No learning curve. No re-training.
"We used to lose hours just tracing where a box went. Now, I can find it in seconds, even see its full history. It's a relief."
"The tool feels like it was built by someone who actually sat with us and understood what we do. No training needed, it just made sense."
A System That Works Because It Listens
IMS wasn’t built to showcase features, it was built to solve real problems. It came from observing, asking, listening and translating workflows into calm, structured steps.
It wasn’t just about inventory. It was about clarity. About helping TCCL feel in control of a system that used to feel chaotic.
"This didn't just solve inventory. It changed how we feel about the process, everything finally feels manageable."