I designed and built HPDash OS: an operations system for a rural LPG distributorship whose government portal took too many steps and slowed to a crawl under its own data. What the business needed instead was something user-friendly, a real operating system for the people running it, not just a record of them.
Give a rural LPG distributorship a system of insight to sit alongside the government system of record: one place to find any consumer, see who needs contacting, assign that work, and know it got done.
The HPCL portal answered only HPCL's questions. An LPG distributorship delivers cooking gas cylinders to households across a cluster of villages. HPCL built the portal to keep records, not to run a business. Every consumer, every refill, every KYC status sat inside it, and none of it was usable.
To look up one consumer, staff needed the ID printed on the physical LPG copy. No name search, no phone search, no village search. But consumers call and say their name and their village, so the most common enquiry in the operation failed before it started.
Everything above the individual record was worse. There was no way to ask who hasn't refilled in two months, or who still has KYC pending. Nobody can build those lists one lookup at a time, and one lookup at a time was all the portal allowed. Meanwhile the work built on that data lived in Excel sheets and the owner's memory.
In the HPCL portal, I can't see all the data in one place. I have to log in many times and download data.
Consumers give their name and their village, not a consumer number. The portal only ever gave them one way in.
I interviewed the owner and watched him work before I designed anything. The pain he named first wasn’t slowness. It was the number of steps between a question and an answer: log in, password, OTP, search, and often an export to a spreadsheet, on infrastructure that stalls under national load.
Then one thing from that session changed the scope entirely. His real job isn’t looking up consumers, it’s directing five people. He tracked assignments across Excel and memory and couldn’t say at the end of a week what had actually been done. The lookup problem was visible. The accountability problem was expensive. That reframed the brief from a search tool to an operations system.
I also found something neither of us expected. Roughly 72% of all bookings arrive through IVRS, with the distributor’s own channels near zero. He’d never seen it, because nothing had ever aggregated it.
Steps 1 to 4 ran on HPCL. Step 5 ran on Excel. Steps 6 and 7 ran on memory.
The record keeps itself. Nobody has to remember.
I built a parallel system, not a replacement. HPCL stays the system of record. Data flows in by CSV, and the layer on top does what the portal won’t: index it, segment it, act on it.
The trade-off: data is only as fresh as the last upload. For a business that plans in days, not seconds, that was the right price. HPCL owns the record. HPDash owns the work that happens because of it, and that split is what let a system built in a month and a half stay simple enough to trust.
HPCL is untouched. Everything right of the CSV boundary is what I built.
Beyond the numbers: the system is in daily production use by all five staff, and the HPCL portal has gone from the daily working surface to a background source of record. They built their own thing and stopped going back.
One dashboard now gives the owner everything at a glance: total consumers, who’s active, eligible, or overdue, refill trends, booking channels, and workload by employee, all updated with a CSV upload. What used to live in his head or scattered exports is now one screen.
Finding a consumer got just as easy. Staff used to need the ID printed on a physical LPG book; now a name, phone number, or village is enough. Smart filters, eKYC pending, eligibility, contact status, assignment, turn that same search into instant segment lists, so a problem’s size is visible before anyone opens a record.
This is the part that replaced Excel sheets, notebooks and the owner’s memory. He opens a consumer, picks an assignment type, an eKYC reminder, a refill call-back, a lead follow-up, sets a due date and a priority, and hands it to a person on the channel they’ll actually use: call, SMS, WhatsApp or a field visit. The assignee is notified immediately and works it from their own queue.
Every action writes to the Activity Center: calls logged, notes added, CSV imports, all filterable by person, type and date. The owner sees everything; each employee sees only their own. I designed that asymmetry as the accountability mechanism itself, because the record exists whether or not anyone thinks to ask for it.
Leads run the same discipline against enquiries that aren’t consumers yet. A cold call or a walk-in gets a name, phone, village and source logged in one screen, then carried through follow-up to conversion instead of living in someone’s memory until it’s forgotten.
The delivery vehicle reaches each village on a schedule, and consumers used to phone the agency to ask when. Scheduled WhatsApp messages now go out two days ahead, so the customer knows the date and is home for it. Fewer inbound enquiry calls, fewer missed deliveries.
The same channel drives reactivation. Any segment the dashboard can produce, including consumers who haven’t refilled in over two months, can be messaged straight from the list, and Outreach History logs what went to whom. The value isn’t the messaging, it’s that segmentation and contact became one motion instead of two disconnected ones.
