Internet and cable
When an area goes down, the whole area calls.
An internet provider has a traffic pattern no other trade has: the line is quiet until a cable is cut, and then two hundred calls arrive in ten minutes, all about the same thing. People do not want a ticket, they want to know whether it is known.
The assistant takes the report, identifies the subscriber by phone number, says what is already known about an outage in that area, opens the ticket with the address and the symptom, and passes to engineering anything that does not fit the general outage.
What rings on the support line
The distinction that matters is between an individual problem and an area problem, because the second has an answer that can be given in the first second.
An individual fault
The address, what is not working, since when, which lights are on the equipment.
A known area outage
Announced in the first seconds, with the estimated time if you have one, which shortens the call to twenty seconds.
The status of a ticket
Searched by number or subscriber, with the status read from your system.
Booking an engineer visit
A window from the field team calendar.
Commercial requests
A new subscription, a move, a plan change. Taken as a lead and passed to sales.
How two hundred calls at once are answered
The real advantage is not that the assistant fixes the fault, it is that it can say the same twenty words two hundred times in the same minute, with no queue.
- 01 Identify the subscriber By phone number, through an HTTP tool over your system. When it finds nobody, it asks for the address.
- 02 Check for a known outage Either through a tool that returns active outages by area, or from a note you change in a document when an outage starts.
- 03 Say what is known If the outage is known, it announces it immediately and closes briefly. That is the part that empties the queue.
- 04 Open a ticket for everything else For individual problems, a ticket in Zendesk or Freshdesk with the address, the symptom and the equipment state.
- 05 Book or escalate A visit window from the calendar, or a transfer to engineering for anything above the thresholds you write.
What stays in support
In the middle of an outage, the number of calls received per area is itself useful engineering information.
| The ticket | With the subscriber, the address, the symptom and the time, in Zendesk or Freshdesk. |
|---|---|
| The volume per area | The structured result on every call carries the area, so it is visible where the calls are piling up. |
| In the calendar | The booked visit, with the address and symptom in the description. |
| On the call record | The transcript and the ended reason, plus whether the call closed on a known outage. |
What it does not do for an internet provider
The temptation is to believe the assistant can do level-one troubleshooting. It cannot, because it can touch nothing.
- It does not troubleshoot or restart anything It does not walk a subscriber through resets, does not reboot equipment remotely and does not test a line. The tools that could execute anything refuse to run in this build.
- It cannot see your network It has no access to monitoring and does not know by itself that an area is down. You tell it, through a tool or through a document.
- No link to your subscriber system There is no connector for subscriber billing and administration platforms. The link is your own HTTP tool.
- It does not identify the subscriber with certainty A phone number is not authentication. For any contract change or personal data, a person is required.
- It does not replace the engineering desk It can open a ticket and transfer. It does not prioritise outages and does not send crews.
What internet providers ask us
How does it learn about an outage in order to announce it?
Most simply, through a document you change when an outage starts, which the assistant reads from the knowledge base. Better, through an HTTP tool that returns active outages by area from your system. The first takes five minutes; the second needs development.
How many calls can it take at once?
The practical limit comes from your telephony account, not from the size of your support team. What has to be said honestly is that we have not yet run a real peak of hundreds of simultaneous calls, and the status page states what has been run.
Can it run line tests?
No. The shell and computer tool types refuse to run in this build, and the sandbox they should execute inside does not exist. If you have an API that returns the state of a line, the assistant can read it through a tool — but it reads, it does not execute.
Does it work for commercial enquiries?
Yes, but a separate assistant is worth it, routed on what the caller says at the start. The first-line triage and routing page describes that pattern.
Where to go next
Telephony
Numbers, trunks, dial plan, queues, operators and campaigns, in one system.
Tools and MCP
Discovery, per-tool permissions, per-server namespacing, and a tool of your own.
Integrations
25 business connectors, 18 selectable providers, eight storage destinations.
Pricing
Components at their published price, the platform on top, and what we cannot price yet.
Notes
-
1
The tools named on this page are the ones in
App\Services\Integrations\ConnectorRegistrycarryingimplemented. Anything that is only in the catalogue, without that flag, is not named here as though it worked. - 2 The current-outage note can live in a knowledge base document and is changed without rebuilding the assistant. The shell and computer tool types refuse to run in this build.