Product Management
The 17:1 e-way bill gap: diagnosing B2B adoption
· Updated · 5 min read
S
Get AI Workflow Teardown Template
The template I use to map AI workflows before writing a spec.
No spam, unsubscribe anytime. I only email teardowns.
The short answer
At LiveKeeping, PRO+ users generated E-Way Bills in Tally rather than in the app — a 17:1 adoption gap hiding in white noise. A two-week deep-dive diagnosis mapped the real workflow and produced a C-suite narrative so clear it changed the product roadmap.
For every one merchant generating an e-way bill in our app, seventeen were generating it in Tally. We had shipped the feature, demoed it, celebrated it — and the dashboard that showed "usage" never once asked where the other bills were being made. A compliance SaaS with 50K+ Indian SMBs lives or dies on where merchants actually do bookkeeping, and the most dangerous number in B2B product is the one your analytics can't see: substitute behavior.
The set-up
- Native e-way bill generation exists; it's a top-of-funnel "PRO+ feature" (e-way bills are mandatory for goods movement above ₹50,000 under GST)
- Analytics showed usage, but nothing about substitute behavior
- Support tickets hinted at Tally; nobody quantified it
The two-step diagnosis
Step 1 — Workflow tracing. We interviewed and instrumented a handful of merchants and discovered the real pattern: generation happens where the invoice lives, which is Tally for a majority.
Step 2 — Quantify the gap. We measured in-app vs external (Tally) generation — and saw a 17:1 preference gap in the revenue-month sample.
The same logic produced a 19:1 E-Invoice gap — the native e-invoice module suffered the identical gravity problem. Two features, same root cause, same magnitude.
How we actually traced the workflow
We didn't guess. We ran a two-week sprint with three parallel tracks:
Track A: Merchant interviews (12 merchants, 45 min each)
We asked them to screen-share their last E-Way Bill generation. Every single one opened Tally, not LiveKeeping. The pattern:
- "I create the invoice in Tally → press F11 → E-Way Bill generates"
- "Why would I switch tabs? The invoice is already here."
- "Tally prints the bill with the invoice. One PDF."
Track B: Instrumentation (GA4 + custom events)
We added events to the in-app E-Way Bill flow:
ewaybill_flow_start→ewaybill_form_view→ewaybill_submit→ewaybill_success- Funnel showed:
2,840 starts → 1,120 form views → 340 submits → 298 successes - Drop-off at form view: 60%. Users saw the form and left.
Track C: Support ticket + search log analysis
- 340 tickets in 90 days mentioning "E-Way Bill" + "Tally"
- Search queries: "Tally E-Way Bill", "import E-Way Bill from Tally", "LiveKeeping E-Way Bill not working"
- Zero searches for "how to use LiveKeeping E-Way Bill"
The triangulation was unambiguous: the workflow lives in Tally. Our feature was a detour.
The gravity problem
Once you see one gap, you check every feature that competes with the merchant's home system. The e-invoice module showed a 19:1 gap by the same measurement — two features, same root cause, same magnitude.
Why gravity wins
E-Way Bill and E-Invoice are compliance events, not product experiences. The merchant's mental model:
- Invoice creation → happens in Tally (daily, core workflow)
- Compliance generation → happens immediately after invoice creation
- Switching context → cost = time + error risk + mental load
Our in-app feature asked them to: finish invoice in Tally → switch to LiveKeeping → re-enter or import data → generate → go back to Tally. That's 4 context switches for a 30-second task. Gravity wins.
The middleware solution (what we actually built)
The pivot wasn't "improve the UI" — it was build a Tally connector. Here's the architecture:
┌─────────────┐ ┌──────────────┐ ┌────────────────┐
│ Tally │────▶│ Connector │────▶│ LiveKeeping │
│ (on-prem) │ │ (middleware)│ │ (cloud) │
└─────────────┘ └──────────────┘ └────────────────┘
│ │ │
▼ ▼ ▼
Invoice XML Transform & E-Way Bill/
(Tally format) Validate E-Invoice API
The connector — a lightweight Windows service (C# .NET 6) that merchants install alongside Tally:
// Connector service — simplified
public class TallyConnector : BackgroundService
{
private readonly HttpClient _http;
private readonly TallyXmlParser _parser;
private readonly LiveKeepingApi _api;
protected override async Task ExecuteAsync(CancellationToken ct)
{
while (!ct.IsCancellationRequested)
{
var invoices = await _parser.WatchForNewInvoicesAsync(ct);
foreach (var invoice in invoices)
{
var ewayBill = await _api.GenerateEwayBillAsync(invoice);
await _parser.WriteBackToTallyAsync(invoice.Id, ewayBill);
var einvoice = await _api.GenerateEinvoiceAsync(invoice);
await _parser.WriteBackToTallyAsync(invoice.Id, einvoice);
}
await Task.Delay(TimeSpan.FromMinutes(5), ct);
}
}
}
Key design decisions:
- Push, not pull — The connector watches Tally's data folder for new invoice XML files. No polling Tally's ODBC (slow, fragile).
- Idempotency — Every invoice gets a UUID. Re-processing the same XML is safe.
- Offline-first — If LiveKeeping API is down, the connector queues locally (SQLite) and retries with exponential backoff.
- Zero-config for merchants — Auto-discovers Tally data path from registry. One-click install.
The rollout (how we got 50K+ merchants on the connector)
We didn't push to everyone at once. The rollout:
| Phase | Merchants | Duration | Success criteria |
|---|---|---|---|
| Alpha | 50 (hand-picked) | 2 weeks | 95% success rate, under 2 min latency |
| Beta | 500 (opt-in) | 4 weeks | 98% success, under 1 min latency |
| Gradual | 5,000 (cohort) | 6 weeks | 99% success, under 30 sec latency |
| General | 50,000+ | 8 weeks | 99.5% success, under 15 sec latency |
The alpha feedback that changed everything:
- "It works, but my antivirus flags the installer" → Signed the binary with EV certificate
- "Tally crashes when connector runs" → Added Tally version detection, graceful fallback
- "I need to see failures in Tally" → Added Tally-side log viewer (F12 in Tally)
The result
| Metric | Before | After |
|---|---|---|
| E-way bill adoption gap | 17:1 (Tally:in-app) | Roadmap pivoted to middleware |
| E-invoice adoption gap | 19:1 (Tally:in-app) | Same pivot |
| C-Suite escalation | none | Funded middleware path |
| Rejection rate (compliance) | baseline | −58% (rejection reasons tracked) |
| Connector install rate | — | 87% of PRO+ |
| Avg generation latency | — | 12 seconds |
What I'd do differently
- Run the workflow trace before the honeymoon. We found Tally-origin volume after the feature demo.
- Report the two numbers together. A 17:1 and a 19:1 in one slide is a stark picture; I'd raise it in the first measurement pass, not after.
- Build the connector as the MVP. The native feature was never the product; the connector was.
Adoption isn't a feature problem — it's a workflow problem. Users don't switch tools; they extend the one their day already lives in.
Read the whole story in the compliance gap case study. The same instrument-first habit runs through the data deep-dive method, and the lifecycle side of this product is in the push notification architecture.
Frequently asked questions
What is a product adoption gap diagnosis?+
A structured investigation of why users ignore a core feature — using data, interviews, and workflow mapping to find the why.
How do you find why users don't adopt a feature?+
Trace the real workflow users settle on instead, then reconcile it against the built feature with quantifiable drop-off rates.
What changed after the 17:1 diagnosis?+
The executive narrative showed ecosystem gravity and a redirectable roadmap — a 17:1 and 19:1 gap detected in one study.