IT support companies have a sorting problem at the front door. The same contact form, the same chat box and the same inbox receive two completely different kinds of message. One is a finance director at a 30-person firm asking what managed support would cost. The other is a receptionist at an existing client saying nobody in the office can print, and could someone look at it now please.
Both matter. They just need opposite handling. The first wants a thoughtful reply and a sales call. The second wants a ticket number in the next minute and an engineer shortly after. When both land in the same place, the prospect waits behind a pile of printer problems, or the printer problem sits in a sales inbox until Monday.
An AI receptionist for IT support earns its keep by doing that sorting at the door, on your website, before anything reaches a person.
Two questions that split the traffic
You do not need a long qualifying script. Most managed service provider enquiries can be routed with two early questions: is this about an existing support agreement, and what is the company name. From there the conversation goes down one of two tracks.
| Prospective client | Existing client | |
|---|---|---|
| What they want | Scope, price range, how onboarding works | Their problem fixed |
| What the assistant collects | Headcount, sites, current setup, pain points, timeline | Company, user, device, symptoms, how many people affected |
| Action | Capture a lead, send to sales | Open a numbered support ticket |
| Speed that matters | Same working day | Minutes, if it is urgent |
| Who picks it up | Account manager or owner | Service desk |
Keep the wording plain. "Are you already a client of ours, or looking for IT support?" works better than anything clever. Technical people are the least patient visitors you will ever have.
Turning a vague complaint into a usable ticket
The worst IT support tickets are the ones that say "email not working". An engineer then spends the first ten minutes emailing back to ask which user, which device, since when and whether anyone else is affected. A website assistant can ask those questions while the client is still in the conversation.
Here is the kind of exchange worth designing for:
Visitor: Hi, Outlook keeps asking me for my password and won't accept it. Assistant: Sorry about that. Are you an existing client of ours? If so, which company are you with? Visitor: Yes, Harper and Lowe. Assistant: Thanks. Is it just you, or are other people in the office seeing the same thing? And is this on a work laptop, a phone, or both? Visitor: Just me I think. Laptop and phone. Assistant: Understood. I have opened ticket 4817 with those details and marked it as affecting one user. The service desk will be in touch. If you realise more people are affected, reply here and I will update it.
The client company, the invented ticket number and the details are illustrative, but the structure is the point. By the time an engineer opens the ticket, the first round of questions has already been answered.
SpideyChat's support ticket action gives each ticket a number, and the webhook action can post the same details as JSON to whatever you already run, whether that is a helpdesk, a Slack channel or a Zapier workflow. The mechanics are covered in turning chats into support tickets.
Outages are not tickets
A single user locked out of email is routine. Nobody at a client site able to reach the file server is an outage, and it should not sit in a queue next to a password reset.
Decide what counts as urgent before you switch anything on. A workable definition for most IT support companies:
- Multiple users affected: anything described as the whole office, everyone or a whole site.
- Security concern: suspected phishing that someone clicked, unexpected encryption of files, a lost device with client data.
- Business stopped: tills, phones, line-of-business software or internet down during trading hours.
- Named critical systems: anything your contracts define as priority one for a particular client.
When a conversation matches, the assistant should say plainly that this is being treated as urgent, collect the minimum needed, and escalate. During the working day that might be a live transfer to whoever is marked on duty in the inbox. Out of hours it might mean showing the emergency number published on your site. The broader principles are in urgent vs routine enquiry triage.
One caution. The assistant cannot see your monitoring tools, so it cannot confirm whether a service is actually down. It should never tell a client "there is no outage". It should say it has logged the report and someone is checking.
What to teach it, and what to leave out
The knowledge base for an IT support company is lopsided. Prospects ask about the same dozen things. Clients ask about everything.
For prospects, write clear pages or Q&A pairs on what your support covers, typical onboarding steps, response targets you are genuinely willing to publish, whether you support Mac as well as Windows, whether you do on-site visits and your service area. If you publish pricing bands, include them. If you do not, say how a quote is worked out.
For existing clients, keep it to safe self-service: how to reach the portal, how to reset a password through it, how to report a phishing email, office hours and the out-of-hours route. Avoid anything contract-specific. The public assistant is on a public website, and a visitor claiming to be from a client company is only claiming it.
That last point deserves its own rule: the assistant should never reset credentials, reveal configuration details or confirm who has access to what. It collects and passes on. Engineers verify and act.
Setting it up in a sensible order
- Write the two routing questions and the urgent criteria before touching any settings.
- Crawl your service pages so prospect questions are covered from content you already have.
- Add Q&A pairs for the self-service basics clients ask about most, taken from your last month of tickets.
- Switch on lead capture for prospects and the support ticket action for clients, and leave everything else off.
- Connect a webhook to your helpdesk or a Slack channel so tickets arrive where engineers already look.
- Test with ten real past enquiries, including at least two outages and one suspected phishing report.
- Check the unanswered questions list after the first week and fill the gaps.
A clear breakdown of the available actions is on the features page, and there is a sector overview for IT services.
Where to start this week
Pull your last 50 inbound messages, from the contact form and the support inbox together. Mark each one as prospect, routine client issue or urgent client issue. Then write down, for each urgent one, what the engineer needed to know first.
That list is your ticket template and your escalation rule. Once you have it on paper, configuring an assistant around it takes an afternoon, and you will know exactly what good looks like when you test it.