Customers and subscriptions in one place
Every customer record, subscription and status change lives in a single source of truth, with invoicing built in using the templates and tax handling specific to the Lebanese telecom context.
Solution · Internet service providers
ISP billing and support, rebuilt around how the team actually works.
Hephon is an AI agency in Dubai (Hephon L.L.C-FZ) that builds operations platforms and support agents for internet service providers and other subscription businesses. For a Lebanese ISP with roughly 2,000 customers, we replaced a 25-year-old billing system in three months and added a self-service bot and an AI assistant.
What does an ISP billing and support agent do?
It puts customers, subscriptions, invoices and collections in one platform that stays in sync with the RADIUS server, so a suspension or a payment takes effect on the network within seconds. Customers handle routine requests through a messaging bot, and staff ask the AI assistant questions about their own data in plain language.
At a glance
- 3 months
- to replace a 25-year-old billing system
- ~2,000
- customer records moved to one database
- 2 days → ~3 hours
- month-end reconciliation
- 13
- feature requests from the team within two months of launch
The problem, in the owner’s words
“The manual work we thought was just part of the job turned out to be the easiest thing to fix.”
The business ran on two systems that had never been properly connected. One was a billing platform built on technology that was already 25 years old. It billed customers reliably every month, but it had been patched by so many people over so many years that nobody could fully explain how it worked anymore.
The other was a RADIUS authentication server with a dated admin screen. RADIUS decides who gets network access, so every change in billing had to be repeated there by hand. When someone missed a step, the two systems disagreed: a customer could be inactive in billing and still connected, or paid up and cut off.
There was no audit trail, so nobody could say who changed what or when. Support meant a phone call, because customers had nothing they could do online. Nearly 2,000 customers sat on a setup with no room to grow and no margin for error.
Month-end reconciliation took two days. Launching a new product tier took weeks. The team had come to accept the manual work as part of the job.
What we built
One operations platform built from scratch and shipped in tight cycles over three months, connected to the RADIUS server the ISP already had.
Collector workflows
A structured way to chase outstanding invoices, with status tracking and escalation rules, instead of lists kept by hand.
RADIUS sync in both directions
Changes in either system reach the other. Suspend a customer in billing and network access is cut within seconds; record a payment and access comes back. RADIUS itself was left in place, which kept the project to three months rather than nine.
Network station inventory
Stations live in the same database as customers, so the team can see which infrastructure serves which customer.
A Telegram self-service bot
Customers share their location for service queries, report issues and handle basic account tasks without calling. Telegram was chosen because it is the app this customer base already used. The bot gets a customer to an answer in three or four messages instead of a 12-minute phone call.
An AI assistant for the team
Staff ask questions such as “How many customers in Beirut downgraded their plan last month?” The assistant turns the question into a query, runs it against the database and returns the answer. It supports several AI models and is configured per organisation.
Who approves what
A billing system decides who has internet and who gets an invoice, so every control was agreed with the team before cutover.
Permissions by tier
A customer service agent can do their job without access to billing changes or admin functions. Each role sees what it needs.
A full audit trail
Every customer change records who made it and when. That log is also why reconciliation dropped from two days to about three hours: discrepancies are found by reading the log, not by comparing screens.
Sync rules agreed upfront
The team agreed the conflict resolution rules between billing and RADIUS before the sync went live, so the system never has to guess which side is right.
The old system stayed in charge until the new one earned it
For the first two weeks both systems ran in parallel. The old billing system was authoritative; the new one produced the same outputs or flagged why not. Cutover happened only after the two agreed for ten consecutive days.
How long it took
First 3 weeks
Sat with the operations, customer service and finance teams and watched their actual day, instead of writing a specification of the old system.
Within weeks
The first major version of the platform shipped.
Migration
Migration script run against a snapshot on a Friday, results validated over the weekend, live the following week.
Parallel run
Both systems side by side until they agreed for ten consecutive days, then cutover.
3 months
Legacy system off. Within two months of launch the team sent a list of 13 new feature requests.
We budgeted two weeks of training for the customer service team. They needed closer to five, because years of habits had formed around the old system’s quirks. Plan for that.
What it costs
A focused first build usually lands between a few thousand and a few tens of thousands of dollars (AED or SAR equivalent), depending on how many systems it touches and how clean your data is. We scope a fixed price after a short discovery, so you know the number before you commit.
Questions
Do we have to replace our RADIUS server?
No. On this project RADIUS stayed exactly where it was. A sync layer keeps it consistent with the new platform. Replacing RADIUS as well would have roughly tripled the scope.
Was the self-service bot on WhatsApp?
No, it is on Telegram, because that is the messaging app this ISP’s customers already used. We pick the channel your customers have open every day; WhatsApp is the usual choice in the Gulf.
Did you write a full specification of the old system first?
No, deliberately. A specification of a 25-year-old system mostly describes workarounds for problems that no longer exist. We spent three weeks watching the team work and built for that.
How did you avoid a risky cutover?
The old system stayed authoritative while both ran in parallel. We cut over only after ten consecutive days of matching outputs. The cutover itself was uneventful.
What can the AI assistant answer?
Questions about the business’s own data, asked in plain language: downgrades by area, stations with repeated incidents, figures for the monthly report. The team does not need SQL or to know which screen holds the data.
Is the engagement finished?
No. It is ongoing. New features ship regularly, the Telegram bot has taken on more self-service flows, and the assistant has new query patterns the team uses for monthly reporting.
Want this for your business?
Tell us what you run today. We will say plainly whether this fits, what we would change for your setup, and what a fixed-price first build looks like.