Mission Report · MapMyIndia [Gtropy]Project case study

Mappls Shop Admin & Automated Billing

Billing was done by hand. The interesting part was not automating the maths. It was finding every place a human was quietly making a decision.

Status
Active
Owned
UI/UX owner · PRD author · cross-functional delivery
Replaces
A fully manual billing process
Billing & accounts
80% more productive
Stack
  • Angular
  • TypeScript
  • Spring Boot
  • Odoo
  • Razorpay

ResultsMeasured

80%
More productive, billing & accounts teams · Measured after go-live
30+
Users · shop.mappls.com
Live
Generating revenue
101001K10K100K1M
  • 30+ users
Log scale · faint markers are this site’s other measured figures

I decided

  • The PRD
  • The UI/UX

I built

  • The web app frontend

With the team

  • Cross-functional delivery
Brief

Replace a fully manual billing process with an automated system, and give shop operations a first-class admin surface.

Context

A manual process is never only arithmetic. It carries exceptions, tolerances and judgement calls that were never written down anywhere, because the person doing them never needed them written down.

Users

Shop administrators, the billing team and the accounts team, plus the customers renewing a device subscription at shop.mappls.com.

Discovery

Sat with the people doing the billing and traced one cycle end to end. Most of the time was not arithmetic; it was looking things up, deciding how to treat an edge case, and re-checking work that had no system of record.

Problem

Manual billing is slow, and it is inconsistent in ways that only surface at reconciliation time.

Hypothesis

Automating the calculation is the easy half. If every judgement call the operator was making by hand is captured as an explicit rule, or explicitly surfaced for a human decision, the process becomes consistent, and consistency is what reconciliation actually needs.

Strategy

Build the admin surface and the billing engine as one product with one data model, so the shop record that drives billing is the same record operations edit. No exports, no re-keying.

Prioritization

The rules that cover the majority of bills first; the exceptions as an explicit review queue rather than a growing list of special cases in code. Audit trail before automation of the last few percent.

UX

The admin sees a bill the way an operator would check it: line by line, with the rule that produced each line visible on demand. Anything the system was unsure about is a flagged decision, not a silent default.

Design

Dense tables with generous row height, inline rule explanations, and a review queue that reads as a to-do list rather than an error log.

Technology

An Angular admin console over the Spring billing API, with Odoo upstream for devices and renewal dates and Razorpay for payments. The billing rules live server-side, so the admin surface, the customer checkout and any future automation share one source of truth. Every call goes through one API service that alone owns the base path, because production and the lab box use prefixes that 404 on each other.

Build

Ali owns the UI/UX, wrote the PRD, and drives delivery across the teams involved.

Outcome

Live and generating revenue, with 30+ users. The billing and accounts teams are 80% more productive: the lookups, re-keying and re-checking that filled a manual cycle are now the system's job, and what is left for a person is the flagged decisions.

Learnings

The PRD's most valuable section was the list of things the previous process decided silently. Making those decisions explicit was most of the product work; the code was the smaller part.

Next missionIOCL GeoRTD PipelineThirty thousand routes is not a data problem you solve once. It is a pipeline you have to trust every time it runs.