What to Build for Telecom and Connectivity Providers in India

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: Founder or COO of a regional ISP or MVNO in India — operating in 3–10 cities, 10K–200K subscribers, still running billing and complaints on a mix of spreadsheets and a decade-old provisioning tool — deciding whether to invest in custom software or keep patching what they have

If you run a regional ISP or MVNO in India with 10K–200K subscribers, the highest-return software you can commission this year is not a billing engine replacement. It is an automated dunning and plan-expiry workflow bolted onto your existing RADIUS or provisioning stack, followed by a complaint system with real SLA tracking, followed by provisioning automation that cuts the 2–4 hour manual step out of every new connection. Everything else — new BSS, self-care super-app, AI churn models — is defensible later, but it is not where your revenue is leaking today.

This post is for the founder or COO who already knows the problem is not the product, it is the operations around the product. You have a decade-old provisioning tool, three spreadsheets that matter, a WhatsApp group that functions as your ticketing system, and a vendor on the phone every month pitching a ₹2 crore BSS/OSS overhaul. The question is what to build, and in what order, so that the first thing you ship pays for the second.

The three operational problems that are actually costing you money

Before the build order, the diagnosis. Regional ISPs in India share a remarkably consistent failure pattern, and it has nothing to do with network quality.

1. Lapsed plans that were never formally churned

A subscriber's monthly plan expires. Auto-debit fails, or they were never on auto-debit. Your current system suspends them after a grace period. Nobody calls them. Nobody sends a structured sequence of reminders. Two weeks later they port to a competitor, or they just stop, and you write them off as churn.

They were not churn. They were a collections failure.

Industry data across subscription businesses shows the average company loses around 9% of monthly recurring revenue to failed or lapsed payments, most of which is recoverable (Baremetrics, 2026). In telecom specifically, bad debt can run as high as 2% of total revenue for a typical operator, and the majority was technically collectible but lost due to absent dunning workflows (SimplyAsk, citing Subex). For poorly performing Indian ISPs, monthly churn runs 8–12% versus a healthier 3–5% at better-run operators (BrightCRM ISP Industry Statistics 2025). A meaningful portion of that gap is collections discipline, not product dissatisfaction.

Multi-channel dunning — email plus SMS plus in-app plus a human call on day seven — recovers 70–80% of failed payments versus about 31% for single-channel email-only sequences (Chargebee benchmark cited in Baremetrics). That is the single largest revenue delta available to you from software.

2. Complaints resolved on WhatsApp with no SLA visibility

Customer calls a field tech directly. Tech fixes it, or doesn't. Nobody logs it. You have no idea which areas generate repeat complaints, which techs close fastest, or how many tickets breached SLA this week because there is no SLA — there is just a WhatsApp group and a spreadsheet updated on Fridays.

With roughly 30% of Indian telecom users switching providers each year (TRAI 2024 data cited in IJRASET, April 2025), the cost of a two-day outage with no visible response is a subscriber ported out before month-end.

3. Manual provisioning that adds 2–4 hours per new connection

A new subscriber signs up. Someone manually enters them into the RADIUS server, assigns an IP pool, configures the ONT or router, updates the billing sheet, and WhatsApps the field tech the install address. Every handoff is a point of failure, and the total elapsed time between "paid" and "online" is often half a day or more. On a bad week, it is two days.

You are competing against Jio and Airtel, who activate a new connection in under an hour. Every hour of delay is a cancellation risk before the first bill is raised.

What to build, in order

Build 1: Automated dunning and plan-expiry workflow

This is the one that pays for everything after it. Scope it narrowly:

• A workflow engine that reads plan expiry dates from your existing billing data (even if that data lives in MySQL behind your current tool, or in a Tally export)
• A configurable sequence: reminder at T-5 days, T-2 days, T-0, T+1, T+3, T+7, with channel escalation (SMS → WhatsApp → voice call via a CPaaS like Exotel or Knowlarity → field agent assignment)
• Payment links in every message, routed through Razorpay or Cashfree with UPI autopay enrolment on the success page
• A dashboard showing recovery rate by cohort, by channel, by region
• A webhook into your RADIUS layer to restore service the moment payment clears, not the next morning when someone checks

What changes once it exists: subscribers who would have silently churned get a structured ask across channels they actually read. Recovery of lapsed MRR in the 40–60% range is realistic if you are starting from a single-channel or no-dunning baseline, based on the multi-channel benchmarks above. Field staff stop chasing payments and go back to installs.

What it is bad at: this build will not fix genuine dissatisfaction. If someone is churning because your uptime in their locality is poor, no dunning sequence saves them. It will also surface uncomfortable data — you will learn that some of your "active" subscriber count was fiction.

Shape of the effort: this is a focused workflow tool, not a platform. Think weeks, not quarters, for a first usable version — the drivers that move the number most are how clean your existing subscriber and payment data is, how many channels you want live on day one, and whether your RADIUS or provisioning tool exposes an API or needs a database-level integration. More on how to turn that shape into a real number below.

Build 2: Complaint and SLA system with field-team mobile app

Once collections are automated, the next bleed is complaint handling. Build:

• A ticketing system where tickets are raised from a customer self-care flow (WhatsApp bot, app, or IVR), not only from an internal CSR screen
• SLA clocks per ticket type (no internet, slow speed, billing dispute, new install) with auto-escalation when breached
• A field-team Android app with ticket assignment, route to the subscriber's address on Google Maps, status updates with photo proof, and offline capture for areas with poor coverage
• Dashboards by locality, tech, and ticket type — so you can see that Ward 14 generates 3x the complaints and send a network engineer, not another field tech

What changes: first-contact resolution goes up, same-day closure goes up, and you stop losing subscribers to a two-day silent outage. You also get the data to negotiate harder with your upstream bandwidth provider when their link is the problem.

What it is bad at: this does not reduce the volume of complaints. It makes them visible and routable. If your network genuinely has issues, you will see them more clearly, which is uncomfortable but useful.

Build 3: Provisioning automation

Now shorten the gap between "paid" and "online":

• API or scripted integration with your RADIUS server (FreeRADIUS, Radiusdesk, or whatever OSS or vendor stack you run) so a new subscriber is auto-provisioned on payment confirmation
• Auto-assignment of IP pool, VLAN, and plan speed based on the sold package
• QR-coded ONT/router assignment — field tech scans the device, system maps it to the subscriber, no manual entry
• Install-complete signal from the field app triggers the first billing cycle

What changes: your 2–4 hour manual step collapses to minutes of human work. New subscribers are online the day they pay. First-month cancellation drops because the activation experience is no longer the reason they leave.

What it is bad at: this build is tightly coupled to your specific RADIUS and OLT stack. It is not reusable if you change vendors. Scope it as the integration it is, not as a platform.

What is not worth building yet

Every vendor will try to sell you these. For an operator at your scale, defer them.

• Full BSS/OSS replacement. Your existing billing tool, however old, is working. Replacing it is a 12–18 month project that distracts from the three builds above. Wrap it with APIs, do not replace it.
• AI churn prediction models. You do not need a model to tell you that someone whose plan expired two weeks ago and who has not responded to three reminders is at risk. You need the reminders first. Come back to ML once you have 18 months of clean ticket and payment data.
• Customer-facing super-app. A WhatsApp bot that handles balance, plan renewal, and complaint raising will serve 90% of your subscribers better than a native app nobody downloads. Build the app in year two if at all.
• Network analytics platforms. Useful, but your NOC team's existing tools (LibreNMS, Zabbix, Grafana) cover 80% of what a commercial product offers. Spend on people reading the dashboards, not more dashboards.

What this costs and how long it takes — the model, not a quote

Buyers asking "how much" and "how long" for this kind of build are really asking which decisions move the number. For a regional ISP, four things drive the cost and timeline of the dunning-plus-complaints-plus-provisioning sequence more than anything else:

1. How clean your existing data is. If subscriber records, plan mappings, and payment history live cleanly in one database, integration is fast. If they are split across your billing tool, a Tally export, and three spreadsheets a regional manager updates, data reconciliation is the project.
2. Whether your current provisioning tool has an API. A documented RADIUS API or REST interface collapses provisioning work by weeks. A tool that requires direct database writes or screen-scraping extends it significantly and adds operational fragility.
3. How many channels and payment rails go live on day one. SMS + payment link is a small build. SMS + WhatsApp Business API + voice IVR + UPI autopay + field agent routing is a much larger one. You can sequence these, and you should.
4. Compliance and licensing. If you are a UL-VNO or ISP-licensed operator, TRAI and DoT reporting requirements add scope. An MVNO adds MNO-contract constraints. A lawyer familiar with your license class should review the scope before build — do not take compliance interpretation from a software vendor, including this post.

Illustrative only: a regional ISP with 50K subscribers, a FreeRADIUS stack with a working API, subscriber data in one MySQL database, and a day-one scope of SMS + WhatsApp + Razorpay for dunning plus a basic ticketing system with a field app — that is a smaller, sequenced build measured in a few months of focused engineering, not a year. Change any of those assumptions (dirty data, no API, add voice IVR, add native customer app) and the shape changes materially.

What turns this into a real quote: a two-hour walkthrough of your current RADIUS/billing stack, a sample export of your subscriber and payment data so the scale of reconciliation is visible, and a clear decision on which channels go live in phase one. That is the conversation to have — with us or any serious partner — before anyone writes a number down.

The market context, briefly

India's broadband services market reached USD 16.34 billion in 2024 and is projected to grow at 9.12% CAGR to USD 35.85 billion by 2033 (IMARC Group). As of March 2024, TRAI reported 924 million broadband subscribers served by 1,194 operators — but the top five hold 98.42% of the market, leaving over 1,100 regional and local ISPs competing for roughly 1.6% (TRAI, 2024). The MVNO segment is growing even faster, projected at 10.7% CAGR through 2036 — the fastest nationally globally (Future Market Insights).

The read: there is room for well-run regional operators, but the ones who survive the next five years will be the ones whose operations are tight. Software is how operations get tight.

How CodeNicely can help

The closest analogue in our work to what a regional ISP needs is GimBooks — the YC-backed accounting SaaS we built for small Indian businesses. The hard parts there were the same hard parts a telecom build involves: reliable payment reconciliation across UPI and card rails, WhatsApp and SMS as the primary subscriber channel (not email), dunning and reminder workflows that had to work for users who check a phone six times a day but an inbox twice a week, and integrations with messy existing data. That is the muscle this build needs.

We work with operators who want to own the IP, run the system on their own cloud, and avoid the vendor lock-in that comes with buying a packaged telecom BSS. If that is the direction you want to move, a scoping conversation about your specific RADIUS, billing, and payment stack is the right next step. Our India team can walk your stack with you.

Frequently Asked Questions

Should a regional ISP buy a packaged BSS/OSS or build custom?

For 10K–200K subscriber operators, neither extreme is right. Packaged BSS from large telecom vendors is overbuilt and expensive; a full custom BSS is a multi-year distraction. The pragmatic path is to keep the existing billing core, wrap it with custom workflows (dunning, ticketing, provisioning) that address the actual revenue leaks, and replace the core only when it genuinely blocks growth.

How much does it cost to build custom telecom software for a regional ISP in India?

The honest answer is that the cost depends on four things: how clean your existing subscriber and payment data is, whether your RADIUS/provisioning tool has an API, how many communication channels and payment rails go live in phase one, and your license class (ISP vs UL-VNO vs MVNO). A dunning-first workflow built on a clean stack is a focused engagement measured in months; a full three-build sequence on a messy stack is materially larger. A scoping walkthrough of your current systems is what turns the range into a real number — no serious partner should quote without one.

How long does it take to go live with automated dunning?

The timeline is driven mostly by data readiness and integration surface, not by the dunning logic itself. If subscriber and payment data is in one place and your payment gateway is already Razorpay or Cashfree, the SMS + WhatsApp + payment link core is quick to stand up. Adding voice IVR, UPI autopay enrolment, and a field-agent escalation path extends it. Most operators underestimate the data cleanup and overestimate the workflow build.

Can we keep our existing RADIUS server and billing tool?

Usually yes, and you should. Rip-and-replace is rarely justified for operators at your scale. The more important question is whether those tools expose APIs or require database-level integration — that difference affects both cost and long-term maintainability. An integration-first approach preserves what works and replaces only what blocks you.

Do we need to involve a lawyer for a telecom software build?

Yes, for anything touching subscriber data, KYC, lawful interception compliance, or TRAI/DoT reporting. Your license class determines a lot of the scope, and software vendors — including us — should not be the final word on compliance interpretation. Have your telecom counsel review the data handling and reporting scope before the build begins.