Revolutionizing Subscription Management

Jio had already tested a subscription engine through APIs. It could run recurring cycles, but the graphical management layer was still at an early stage. The team had a basic form for creating and editing plans, while much of the remaining work was handled from the backend.

That made plan creation the natural starting point. A plan is the foundation of a subscription business: it connects what is being sold to its billing frequency, currency, price, usage rules, and lifecycle. Improving this flow would also establish the interaction language for the rest of the product.

Around the same time, I was renting furniture after moving to Hyderabad. A delivery-management issue led to an incorrect recurring charge for three months. Support eventually resolved it, but the experience made the cost of weak subscription operations concrete: a small mismatch can persist through every billing cycle.

This was a personal catalyst, not a substitute for user research. It helped me look beyond the plan-creation screen and frame ChargeIT as an operating layer for people who need to launch, change, price, and monitor subscription offerings without relying on backend intervention.

“Make complex subscription rules manageable without hiding the information operators need to compare and verify.”

The automated engine handled recurring cycles, but the surrounding decisions still belonged to account owners and administrators. They needed to describe the offer, choose how it would be billed, configure currencies and frequencies, and understand how those choices worked together before publishing it.

I treated the plan as a composition of three layers: essential product information, advanced rules, and pricing. This reduced the apparent size of the task while preserving the depth required by an enterprise subscription system.

The first redesign grouped the work into Basic, Advanced, and Pricing steps. It was a pragmatic intervention: improve the most important workflow quickly, establish a new visual direction, and create a base that could absorb more sophisticated pricing later.

Pricing was kept visible as a comparison surface. Frequencies and currencies appeared together, flags made enabled currencies easier to locate, and an operator could edit a price in context instead of opening another page for every variation.

Secondary research and feedback from internal sales teams exposed the limitation of the first pricing direction. Supporting several currencies and billing frequencies was useful, but it did not cover how differently prepaid and postpaid businesses calculate value.

I mapped the recurring models the product would need to express, then reduced the design problem to three decisions: start with prepaid or postpaid, let the business define its own unit of consumption, and keep the operator in one coherent workspace instead of creating a separate interface for every model.

The hardest interaction was editing ranges and tiers while preserving frequency and currency context. The pricing table became the common surface for defining ranges, comparing variants, and making changes without losing sight of the complete model.

Conversations with internal sales colleagues showed that defining a pricing strategy could require competitor research, investment and margin inputs, revenue projections, and repeated stakeholder reviews. One colleague described spending close to two weeks researching and reviewing pricing approaches.

That led to Compass, a pricing-assistance concept rather than a shipped feature. The idea was to use a generative system to organise those inputs, surface comparable market information, and help teams explore the implications of a model before configuring it in ChargeIT.

ChargeIT taught me to design the simple path and the underlying system at the same time. Grouping the initial form created immediate clarity, but the deeper value came from identifying a stable model that could absorb prepaid, postpaid, metered, multi-currency, and multi-frequency configurations.