Notice Tracker.

Indian enterprises were managing thousands of GST notices across emails, spreadsheets, and a government portal that was never designed for compliance teams. A single missed deadline could mean penalties in lakhs, sometimes crores.

The portal returned communications. Teams needed cases. There was no priority signaling, no chronological view, no team workflow. Just a list of documents with cryptic reference IDs, scattered across months.

We did not initially plan to build a notice product. Our enterprise customers pulled us toward it. They kept asking for the same thing in different words: a way to stop losing money to deadlines they could not see.

Before we talked to customers, I spent a week inside the government’s GST portal. Mapped every screen, every workflow, every data field. I needed to know what the system actually returned, not what customers thought it returned.

Then we ran customer interviews. We asked questions in three categories:

Our deepest analysis of the government portal revealed its single greatest flaw. The portal returned a dump of communications without a clear chronological trail. Multiple updates related to the same legal matter could appear as separate items with different reference IDs, scattered across months.

A case is not a document. A case is a conversation between a tax authority and a taxpayer, often spanning multiple stages: Intimation, Notice, Order, sometimes higher courts. The government’s reference IDs were document IDs. We needed case IDs.

So we built the entire product around a single insight: every interaction, every screen, every interaction model anchors to a stable Case ID.

This single decision simplified the entire information architecture. The dashboard could group by case, not by communication. The case list could prioritize by case status, not by document type. The case detail page could show a true chronological history. The AI layer, when we added it later, could summarize across the case lifetime rather than per document.

The Case ID became the spine. Every other design decision flowed through it.

Our research surfaced three distinct user types, each with a different job to be done. The product had to serve all three, but they needed different views.

The CFO needed a 30-second risk view. Total financial exposure, what is overdue, what is time-critical. No need to see individual notices. They just need to know how worried to be.

The Tax Head needed to triage. Which entities carry the most risk? Which team members should handle what? How is the pipeline looking?

The Analyst needed to do the work. Read the notice, gather the data, draft the reply. Maximum context on a single screen, minimum hunting.

I designed three pages, one for each role.

Underneath those three screens sat one structure. Every regime, every notice, and every system layer resolved to the same Case ID.

We launched. The product worked. Customers loved it for GST notices specifically.

Then we extended to Direct Tax notices. We assumed the workflow would translate. It did not.

Within three months, the data was unambiguous. Direct Tax usage was low. Support tickets revealed a fundamental workflow mismatch. The notice formats were different. The deadline structures were different. The user expectations were different.

I led the call to stop active development on Direct Tax. We repositioned it as a sales-assist tool, valuable for opening doors with prospective customers, but not draining engineering resources to maintain as a primary feature.

Two of the three regimes in that architecture came off. Direct Tax moved to sales assist, GST got the depth instead.

Then I made one more decision that turned out to matter: we renamed the product.

The rename was not marketing. It was strategic. Management implied a broad scope. Tracker encoded a narrow promise. The new name told customers what we were and what we were not.

Engagement on core GST features rose. Off-track feature requests dropped. Sales conversations got cleaner because the name did the qualification work.

Tracking solved the organization problem. The remaining problem was comprehension.

Government notices arrive as inconsistent PDFs, often in regional languages, with no standard format. Reading them is slow. Misreading them is expensive.

We added an AI layer with three capabilities:

AI Summaries. A plain-language explanation of what the notice is actually demanding, generated from the PDF content.

Reason Extraction. Automatic identification of the specific reason for the notice. Was it a mismatch? A late filing? An ITC dispute? Surfaced in structured form.

Structured Parsing. The government portal does not return these fields. Users had to read every PDF to find the demand amount, the relevant tax section, the actual due date. We extracted these upfront and populated them directly in the case list table view, so the team could triage at a glance instead of opening every document.

We shipped it in phases. Early Access first, with a small cohort of real customers feeding us their actual notices for training. General Availability followed only when extraction accuracy crossed a threshold where the AI felt invisible.

The principle for the AI rollout was simple: ship as a capability, not a demo. Trust gets earned through accuracy on real data, not through marketing screenshots.