Subscriber asks "why is it down" — the bot answers, not the on-duty engineer
The bot handles routine requests on its own and turns outages into tickets with the address and entrance number. The on-duty engineer sees the board, the subscriber sees the status in the same chat.
- 24/7
- request intake, including nighttime
- 30 min
- on-duty response time during business hours
- 2 weeks
- from audit to launch
What comes into ISP support
-
"No internet"
The most common request. Many are resolved by checking power, cables, and balance — but someone has to tell the subscriber.
-
"When will it be fixed"
During an outage, the exact same question arrives dozens of times. The answer is identical, but it consumes all of the on-duty staff's time.
-
Balance and plan
Account balance, billing date, how to change plans, where to pay. The answer is in the billing system, but a human has to retrieve it.
-
Connection request
New address, additional service, relocation. This is not an outage — waiting on the line here is not needed at all.
What the bot resolves on its own
| Request | What the bot does |
|---|---|
| "No internet" | What the bot does Guides through the checklist: power, cable, LED indicators, balance. If that does not help, creates a ticket with the address |
| "When will it be fixed" | What the bot does Provides the status of an open outage from your system or creates a request if no outage is logged |
| "What is my balance" | What the bot does Fetches the answer from billing after identifying the subscriber |
| "How to pay" | What the bot does Explains payment methods from your page and provides links |
| "I want to change my plan" | What the bot does Accepts the request and forwards it to the sales department along with the contact info |
| "TV is not working" | What the bot does Checks typical causes and creates a ticket for an engineer |
The bot shows billing data only after identifying the subscriber and only the fields you permit. Outage statuses come directly from your system — the bot cannot invent them.
Outage request flow
-
Request
Subscriber messages the bot: address, entrance, what exactly is down.
-
Verification
The bot runs through a standard checklist and stops when it reaches hardware-level issues.
-
Ticket for on-duty engineer
A ticket is created with the address, timestamp, and description. The on-duty engineer gets a notification instead of searching through chat messages.
-
Status for the subscriber
When the work is done, the subscriber receives an update in the same chat — no follow-up calls needed.
If there is already an open outage at the address, the new request is attached to it instead of creating a duplicate.
What this gives the on-duty shift
-
Nights without a night shift
Requests are accepted around the clock, and a human is only alerted for things that truly require a human.
-
Outages do not drown in duplicates
Dozens of identical requests from the same address become a single ticket with a list of affected subscribers.
-
Billing right at hand
Balance, plan, and connection status come directly from your system, not from a separate spreadsheet someone has to maintain.
ISP case studies
All case studiesThe ISP case study is not yet published: we only publish what clients have approved with verified numbers. Tell us about your network — we will show the closest example in a meeting.
What ISPs ask
Will the bot have access to billing?
Read-only, and only to the fields you allow. The subscriber is identified according to your rules: contract number, phone number, or customer portal — until that point, the bot discloses nothing about the account.
What happens during a major outage?
The bot gives the same status to everyone who asks and attaches requests to the already open outage instead of creating duplicates. The on-duty operator doesn't have to rewrite the same response a hundred times.
Our subscribers are older; they don't use Telegram
That is why the bot is deployed both on the website and in the client portal. The phone line remains — it simply offloads the routine tasks that can be resolved via text.
We have our own ticket system
Then tickets are routed to it. The exchange is two-way: the status from your system is returned to the subscriber in the chat they wrote from.
How much of our time will this take?
Audit takes 2 days, knowledge base 5 days, pilot on a segment of subscribers. On your end — someone who knows the tariffs and emergency protocols, for 3–4 hours of discussions.