Skip to content
Case study·

10 min read

·For operators

Case study: AI chat and leaver retention agents for a UK fibre ISP

What we built for a UK fibre ISP on web chat and WhatsApp, how it went live, how we run it every month, what went wrong along the way, and the results so far.

Silviu Major·Founder, Fiveleaf··Updated

Fiveleaf designs, builds and runs the AI agents that answer a UK fibre ISP's web chat and WhatsApp, live since late 2025, along with a second agent that messages customers who have started switching to another provider. At six months live the inbound agents were delivering a net monthly return of about 5:1, and the cancellation conversation saves 71% of the customers coming through our channel to leave.

The situation

The client is a full-fibre ISP selling to homes. Customer service, tech support, billing, sales and retentions each have their own team, and almost everything about a customer lives in one in-house platform that holds the CRM, billing and account records.

The website already had a chat widget. What it did not have was a conversation connected to the account, or a handover that reached the right team with the context attached.

As at most ISPs, every new cost has to show that it saves money.

What we built

It started with a demo agent built in their name, taken through a billing scenario, a sales scenario and a tech support scenario. The build that followed is one inbound agent on web chat and WhatsApp, on a single business number.

For existing customers, the agent identifies the customer before it says anything about the account. The ISP set the rule: at least two factors checked against the account record, and no personal information, the customer's name included, until that check passes. Once it does, the account details are loaded before the agent answers, so it is working from the record rather than from what the customer remembers.

For new customers, it answers questions about the service and qualifies sales enquiries for the sales team.

When a person is needed, the agent routes the conversation to the right department with a summary, so the adviser does not start again. It raises a ticket in the ISP's own system, and a repeat contact about the same issue is recognised rather than logged as a second ticket. Each team gets an alert in its own channel, with an email fallback if the alert fails. Out of hours, the conversation still ends in a ticket rather than a dead end.

When a customer comes to cancel, the agent talks it through with them first, and a cancellation that goes ahead reaches the team as a ticket rather than a live handover.

In autumn 2026 we moved the live handovers for chat and WhatsApp onto our dashboard, so the advisers and the agents now work in the same place.

The leaver agent

The second agent covers customers who have already decided to go. When a customer starts a switch to another provider through One Touch Switch, the ISP's platform tells us. The agent checks the customer has consented to marketing messages, then sends a WhatsApp message with an offer to stay.

The insight it rests on: a customer who switches this way has usually chosen it so they do not have to talk to anyone. A phone call is the thing they were avoiding. A message they can answer in their own time is not.

If they reply, the agent handles it. A price objection gets the next package down. A customer who quotes another provider hears that staying means no exit fee, and the agent never comments on the other provider or what they said. An accepted offer or a request for a call goes to the renewals team as a ticket carrying the whole conversation. Every leaving reason is recorded in the customer's own words, on a page the retention lead can read. We wrote more about this kind of agent in AI for ISPs and altnets: customer retention.

WhatsApp: the same agent on the customer's phone

Most of an ISP's customers already have WhatsApp open every day. Few of them want to sit on hold to ask when their bill is due or why the router light is red. So WhatsApp was never a separate bot here. It runs the same agent as the web chat, with the same knowledge, the same identity check, the same routing and the same handover.

That means a customer on WhatsApp can do everything a customer on the website can. They can report a fault and be taken through the checks, ask about a bill, ask about packages before they buy, pass the identity check and get answers from their own account, and reach a person when one is needed, with the conversation attached. Out of hours, they get a ticket raised for them rather than a closed sign.

WhatsApp also makes the identity check lighter. The customer's number arrives with every message, so it can count as one of the two factors, and the agent needs fewer questions to confirm who it is talking to.

Everything runs on one business number. Customer service, the sales questions and the leaver agent all go out and come in on the same number, the one customers already have saved. It sits on the ISP's own WhatsApp Business account, so the number and the customer relationship stay theirs, and we work on it with partner access.

When we moved the live handovers onto our dashboard in October 2026, web chat and WhatsApp switched over together on one morning, and the WhatsApp number moved with them. That move taught us something worth passing on: the approved message templates belong to the account, not the number, so every outbound template had to be rebuilt and re-approved, and anything that sends from the old number has to be repointed before the switch, not after. One sending path was missed, and leaver messages failed to reach WhatsApp for two days until it was fixed.

What the agents cover today

  • Faults and tech support: troubleshooting from the ISP's own support material, with network outage status built in.
  • Account questions: answered from the customer's record, after the two-factor check.
  • Billing questions: the general ones answered, the account-specific ones routed to billing with the detail captured.
  • Sales: questions about the service, qualification, and the prospect's details passed to the sales team.
  • Cancellations: talked through first, then passed to the team as a ticket.
  • Leavers: a WhatsApp offer to customers who have started a switch away, with consent checked first.
  • Handover: to the right department, with a summary and the conversation, plus an alert in that team's channel.
  • Tickets: raised in the ISP's own system, checked against open tickets first so the same issue is not logged twice.
  • Out of hours: opening hours set per department, and a ticket when the department is closed.

What it means for the ISP's customers

This is what changes for the person on the other end. Where it is our general experience rather than a measured result, we say so.

An answer at any hour. The agent answers at 11pm on a Sunday the same as at 11am on a Tuesday. If what they need can only be done by a person, the conversation still ends with a ticket and the detail captured, so the team picks it up in the morning without having to call them back to ask what it was about.

No queue for the simple things. A question the agent can answer gets answered straight away, without waiting for an adviser to become free.

No repeating themselves. When a person takes over, the adviser sees who the customer is, what they asked and what has already been tried. In our experience, having to explain it all again is one of the things customers complain about most when they contact any provider.

A message instead of a phone call. A customer can start on WhatsApp on the bus, put the phone down and pick it up later in the same thread. For many people that suits them better than a call, and for leavers it is the whole point: they get a simple message they can ignore or answer, rather than a call they chose to avoid.

How it was rolled out

The inbound agent went live in late 2025 and replaced the old widget on the website.

The leaver agent took about nine weeks from signature to go-live. Almost all of that was waiting on integration work on the client's side, because the switch notice and the ticketing both depend on their own tech team. The build itself fits the usual pattern: a second agent on a shared platform takes 1 to 3 weeks of build time. How long it takes to deploy a conversational AI agent goes into why access sets the date, not the AI.

Before launch the scenarios were run in a test harness and reviewed with the client's retention lead, who asked for changes to how the agent answers price objections and competitor mentions. It went live on her written sign-off.

How we run it

We never do one-off builds. We maintain and improve monthly.

In practice that means a shared channel with their team for feedback and edge cases, regular calls with each department lead, and changes made as the business changes. When their team pointed out that the chat was sending customers to a complaints number nobody answered, we switched that route to email the same day. When the fixed opening question (new or existing customer?) turned out to get in the way of the question the customer had actually asked, we replaced it with one open question. When the team leads changed which departments cover for each other, the routing changed with them.

We also prepared a one-year review and roadmap for their management team, built from what the conversations show.

What we learned

System access is the ceiling. We read the handovers to see what still goes to a person. Most of it needs the agent to look something up, arrange something or change something on the account. Billing is the largest share of customer service questions and the agent's biggest gap. The agent also has no installation dates, so every "when is my engineer coming" question ends with a person. The next step for this agent is not making it smarter. It is giving it access to finish what it already understands.

A handover is not complete until something outside our systems confirms it. We had a period where tickets were failing to reach the ISP's system while our own workflow reported every run as a success. We now count tickets raised against handovers and alert on any gap, rather than trusting a green tick.

Test on the live channel as well as in the harness. The live channel opened conversations differently from our test driver, and some first replies were routed wrongly as a result. The harness passed. The live conversations did not.

Consent decides reach. Many leavers had not consented to marketing messages, so the agent cannot contact them at all. That is the ISP's data, not something the agent can fix, and an email route is being added for customers who can be reached that way.

Two populations, two numbers. The 71% comes from customers who chose to talk to us about cancelling. Customers switching away through One Touch Switch chose not to talk to anyone. We keep the two apart and never quote one as the other.

The results

  • About 5:1 net monthly return at six months live, for the inbound agents.
  • 71% cancellation save rate, of customers coming through our channel.
  • Over a third of leavers replied to the leaver agent in its first two weeks live.
  • The leaver agent paid for itself in its first week. It needed two or three saves a month to cover its cost.
  • Every leaving reason in one place, which is the part the client's renewals lead valued most.

The leaver figures are early, from the first weeks live, and we will update them as the agent builds a longer record.

If you want to see what one of these conversations feels like, talk to our agent, or book a call and we will walk you through the build.

Frequently asked

Which systems do the agents connect to?
The ISP's own platform, which holds the CRM, billing and account records, through its API. Tickets are raised in that same system, handover alerts go to each team's channel in their workplace messaging tool with an email fallback, and WhatsApp runs on the ISP's own business account. Live handovers to people run through our dashboard.
Can customers do the same things on WhatsApp as on web chat?
Yes. It is the same agent on both, with the same identity check, knowledge, routing and handover. On WhatsApp the customer's number arrives with every message, which makes the identity check shorter, and the conversation stays in a thread they can come back to.
How long did it take to go live?
A first agent with the shared platform typically takes 4 to 8 weeks to build, a second 1 to 3 weeks. The leaver agent here took about nine weeks from signature to go-live, almost all of it waiting on integration work on the client's side, which is why we quote build time and never promise it as a date.
Why is the client not named?
The client prefers to stay confidential for now. We are happy to talk through the build and the methodology behind the figures on a call.

If you want help building this

We build AI agents that act, then we run them for you.

Bespoke build, fully integrated, continuously optimised. A 30-minute discovery call is enough to tell you honestly whether AI agents fit your team right now, or whether you’re better off waiting six months. No pitch.

About the author

Silviu Major, Founder, Fiveleaf

Silviu Major

Founder, Fiveleaf

A decade in enterprise SaaS, now building and running AI agents that act, for broadband providers and other service businesses. Writes about what works (and what doesn’t) from inside live deployments, not from the outside looking in.

More about SilviuConnect on LinkedIn →

Keep reading