Support at a hosting company is a good place to start with AI, because most of the questions repeat. What does this plan include? How much is a .com renewal? Is this domain free? Which payment methods do you take? And then there is the other kind: "my site is down," which needs a person, but also needs a ticket with the right details in the right department.

These are the questions VividSol, our hosting and domain business, deals with. I built three n8n templates around them, all on Google Gemini and the WHMCS API, and published them on n8n's template library:

These are the design decisions that matter more than the model.

The architecture

All three follow the same outline:

  1. A webhook receives the chat message, so the bot can sit behind any website chat widget, including our open-source Brandable Custom Chatbox for n8n.
  2. An AI Agent node running Gemini reads the message, with session memory so the conversation keeps its context.
  3. Narrow tools give it real data: Google Sheets knowledge bases, the WHMCS domain lookup, and the WHMCS ticket endpoints.
  4. The reply goes back through the webhook.

The model is the conversation layer. Everything it says about prices, availability, or tickets comes from a tool.

Decision 1: knowledge lives in sheets, not in the prompt

The full support template reads from separate sheets for shared hosting plans, domain prices, hosting features, FAQs, payment methods, and company offerings. When the price of a plan changes, someone edits a cell. Nobody touches the workflow, and nobody has to remember that the price was also written into a prompt three months ago.

Putting facts in the prompt feels faster on day one. On day ninety it is how a bot quotes last year's prices with total confidence.

Decision 2: availability comes from the registrar, never from the model

A model has opinions about whether something.com is taken. They are worthless. The domain tools call WHMCS's DomainWhois action and answer only from that result. When the bot suggests alternatives, it checks them too before offering them. A customer told a domain is available, only to find it is not at checkout, loses trust in the whole site, not just the bot.

Decision 3: tickets map to departments that exist

The ticket template does not let the model invent anything WHMCS has to accept. It first calls GetSupportDepartments to get the real list, then the model extracts what it is good at extracting from a messy conversation: the customer's name and email, a subject, a clear description, the right department from that list, and a priority of Low, Medium, or High. The ticket is created through OpenTicket.

The model fills in a form. The workflow owns the API call. That division is why the tickets arrive usable.

Decision 4: identify the customer first

The full support bot asks for a name and email at the start of a session. It feels slightly less magical, but every conversation that later needs a ticket or a follow-up already has an owner. Anonymous chats that end in "someone will get back to you" are how support requests get lost.

Decision 5: a persona with clear limits

The support agent has a name and a friendly, professional tone, because customers respond better to that than to a robotic one. The limits matter more than the personality. It answers from its knowledge bases, checks domains, and hands anything it cannot resolve to the support team. It has no tool to change an account, apply a discount, or touch a service, so no clever message can talk it into doing so.

Where it can go wrong

  • A tool fails and the model fills the gap. If a sheet lookup returns nothing, the model may answer from general knowledge. Tell it plainly to say it will check with the team instead, and treat the knowledge base as the first suspect when a conversation goes wrong.
  • Prompt injection through the chat box. Customers, or people pretending to be customers, will try "ignore your instructions." The best defense is the one above: the agent has no tool that could do damage.
  • Over-privileged API credentials. Store the WHMCS credentials in n8n's credential system, not in a node's text field. WHMCS lets you limit what an API role may do and restrict API access by IP address. Give the bot only the actions it needs: domain lookups, listing departments, and opening tickets.

The same lookup, as an MCP tool

The domain check also exists on this site as a Laravel MCP tool, so any MCP-capable AI client can use it. It is the same idea with stricter edges: the domain is validated against a pattern, lowercased, and checked through a small WHMCS client class, and any WHMCS error comes back as a clear tool error instead of a guess. One capability, two front doors, the same rule: the registrar decides, not the model.

What I would measure

If you run something like this, three numbers tell you most of what you need:

  • Questions with no answer in the knowledge base. Each one is a row to add to a sheet.
  • Tickets that end up in the wrong department. This points at the extraction prompt or the department names.
  • Conversations that reach a person. It should fall over time, but never to zero.

My take

A support bot for a hosting business is not a big AI problem. It is a data problem with a conversational front end. Keep the facts in places your team already edits, let the registrar and the billing system answer for themselves, and give the model the one job it does better than any form: understanding what the customer actually meant. For the reasoning behind that split, see Workflow First, Agent Second.