AI live chat for hosting companies: fewer tickets, faster answers

Run a hosting company for a month and you can predict the queue. Where do I point my domain. Why is my site down. Did my payment go through. Can you move my site from the old host. The questions arrive at every hour, most of them have the same answer, and each one still costs a person fifteen minutes.

That is the part an AI assistant is good at. Not the hard migrations, not the angry escalations, but the steady drip of questions your team has answered a thousand times.

What hosting clients actually ask

Look at a week of tickets and they sort into four piles.

Domains and DNS. Which nameservers to use, why the site still shows the old host, when a domain expires, how to move it in. These are answerable in one message if the assistant knows your nameservers and can read the domain.

Billing. What is due, when, why an invoice appeared, how to pay it. Most of these are lookups, not decisions.

Something is broken. The site is down, email stopped, the control panel login fails. Half of these turn out to be an unpaid invoice or a known outage.

Pre-sales. Which plan fits, can you host WordPress, do you do migrations. Answer this in the first minute and you get the order. Answer it tomorrow and they bought elsewhere.

Reading your knowledgebase is not enough

Most AI chat tools stop at your documentation. They read your help articles and answer from them, which handles the how-to questions and nothing else.

A client asking "why is my site down" does not want an article about suspensions. They want to hear that their invoice from 3 September is unpaid and their account was suspended this morning, with a link to pay it. That answer lives in WHMCS, not in a help article.

This is the split worth thinking about before you buy anything. General questions come from your content. Account questions come from your billing system. Only the second kind ends tickets.

Connecting WHMCS without handing over the keys

The obvious way to connect an AI to WHMCS is the admin API. It is also the wrong way. An admin credential can read and change every client in the system, so the only thing protecting your customers is the AI vendor getting every check right, forever.

MagizAI takes a different route. You install a small free module inside your own WHMCS. The assistant can only call that module, and the module only performs the actions you switch on in its settings.

Two things make it safe enough to leave running overnight.

WHMCS decides who is asking. When a client loads a page in your client area, the module signs a short lived token for that client. Every request is verified again inside WHMCS before anything is read, so a compromised chat vendor still cannot act for someone who is not signed in.

Every lookup is scoped to that client. Domains, services, invoices and tickets are fetched under the signed in account. Ask about a domain on someone else's account and you get the same answer as for a domain that does not exist.

Letting it change things, carefully

Answering questions is easy to feel comfortable with. Changing a live domain is different, and it should be.

Nameserver changes are the common case worth automating, because clients ask for them constantly and the change itself is mechanical. The flow we settled on looks like this:

1. The client asks to point a domain at new nameservers.
2. The assistant checks the domain is on their account, then reads back exactly what will change.
3. The client types a one time code shown in the chat.
4. The change goes through, WHMCS logs it, and the client gets an email.

The code expires in ten minutes and works once. If the client walks away, nothing happens. If they change their mind, they type cancel.

The same pattern covers auto renew, opening a ticket, replying to a ticket, and cancellation requests. Transfer codes are treated differently: the code is emailed to the address on the account and never shown in chat, because a transfer code is the key to moving a domain away from you.

What it should refuse

A support assistant that tries to answer everything will eventually be confidently wrong about something expensive. Ours refuses in a few specific places.

It does not read passwords, card details or transfer codes, because they never reach the chat in the first place. It does not act for a visitor who is not signed in. It does not change anything for a client whose sign in is older than an hour, since the person at the keyboard may no longer be the person who signed in. And when it cannot solve something, it opens a ticket or hands the chat to your team rather than guessing.

The part people forget: keeping it current

Prices change. Plans get retired. A new data centre opens. If the assistant learned your business once during setup, it starts lying quietly a month later.

The module syncs each night: knowledgebase articles, announcements, products and prices, your nameservers, support departments and domain pricing. Only changed items are sent. Delete an article in WHMCS and the assistant forgets it too. Client data stays inside WHMCS.

Is it worth it for a small host?

If you have two people answering tickets and one of them is you, the calculation is simple. Count the tickets from last week that were answered with a link, a date, or a number already sitting in WHMCS. That is the pile an assistant takes.

For most hosts it is a third to a half of the queue, concentrated in the hours when nobody is awake.

Getting started

The MagizAI module for WHMCS is free and open on GitHub. It works with WHMCS 8.0 or newer on PHP 7.4 or newer, and setup runs about ten minutes: upload, activate, paste two keys, then choose which actions the assistant may perform.

Start with lookups only. Watch a week of real conversations in the inbox. Then switch on nameserver changes when you can see what it is actually saying to your clients.

See how the WHMCS module works or read about AI live chat for hosting businesses.