AI Chatbot for Managed IT Providers

One brand, two chatbots with nothing in common

The chat bubble on your marketing site and the help channel your clients’ employees use can look alike. Underneath, they should share almost nothing: not the knowledge base, not the permissions, not the escalation paths.

The prospect bot lives on your public website. Its job is qualification: how many users and locations the business has, what it runs today (an in-house IT person, another provider, nobody), which line-of-business applications matter, what triggered the search, and whether they have outside requirements from insurers or customers they want to talk through. It books a discovery call with your sales lead. It knows your service descriptions and nothing about any client.

The support bot serves people at companies you already manage. It lives where those users already are, most often Microsoft Teams, sometimes a client portal or a chat widget on your support page. It can read from your PSA and sometimes your RMM, it creates tickets, and in narrow cases it may run pre-approved actions. Everything about its design starts from the assumption that the person typing might not be who they claim.

Keeping them separate is not a stylistic choice. A single bot with access to client data sitting on a public web page is one prompt-injection attempt away from leaking something. Two bots with two scopes remove that failure mode instead of trying to guard against it.

Verify first: the help-desk social engineering problem

Attackers have learned that a help desk will often do what a firewall will not: reset a password or re-enroll multifactor authentication for someone who sounds stressed and in a hurry. A chatbot that can trigger those actions becomes the easiest version of that attack, available around the clock and immune to the gut feeling a good technician gets on a strange call.

So the support bot sorts every action into tiers, and your service manager signs off on the tiering before anything is built:

Two further rules close common gaps. The bot never reveals whether an account exists, so it cannot be used to confirm valid usernames. And it never accepts contact details offered during the conversation as a verification channel; a code sent to a phone number the visitor just typed proves nothing.

Turning “my computer is broken” into a ticket a technician can work

Most tier-one time goes to reconstructing what the user meant. The bot’s biggest contribution is asking the follow-up questions a dispatcher would ask, before the ticket exists, so that it arrives already usable.

• Who and where. Company and contact come from the sign-in, not from typing. The bot asks which device is affected and, where your RMM is connected, can offer the user’s own machines by name to pick from.
• What happened. What the user was trying to do, the exact error text or a screenshot, and when it started.
• Blast radius. Whether coworkers have the same problem and whether the user can work at all. These two answers drive priority more than anything else.

The bot then proposes a priority from your impact-and-urgency matrix, a board or queue, a type and subtype, and a one-line summary a technician can scan. Compare a user’s message of “outlook not working help” with the ticket the bot writes: Outlook desktop on user’s laptop shows repeated password prompts since 9:10; webmail works; one user affected; user can work in the browser. Nothing in that summary is invented; each clause is an answer the user gave.

Duplicate handling matters at MSP scale. When eight people at the same client report that the internet is down within ten minutes, you want one incident with eight contacts attached, not eight tickets. The bot checks for open tickets at the same company with matching symptoms, and, where your RMM shows a site offline, attaches new reports to the existing parent ticket and tells each user the issue is already being worked.

Reading the agreement before promising anything

Your PSA already knows which users and devices are covered, which hours support is included, and which work counts as a project. The bot reads that so it can route correctly. It does not tell users what is billable. A dispatcher who sees the agreement, the client relationship and the history is in a far better position to have that conversation than an automated assistant is.

Agreement awareness does change a few behaviors. Requests that require client authorization, such as a new hire’s account, a software purchase or access to a shared mailbox, go to the approver your client designated rather than straight to a technician. Requests from people who are not on the covered contact list get logged and routed to the account manager instead of silently rejected. And project-shaped requests, like moving an office or rolling out new laptops, get flagged for the account manager, because they should never enter the service queue as an ordinary ticket.

What the bot may fix, and what it should only write down

There is a real list of problems a verified user can solve with good guidance: reconnecting to the VPN, clearing a stuck print job, finding a file in the recycle bin or version history, setting up an out-of-office message. The bot walks through those from articles your team wrote, and when a client has its own quirks, such as a specific printer naming scheme or a separate VPN profile, those client-specific notes go into the knowledge base with that client’s scope attached.

Some MSPs want the bot to go one step further and run a scripted fix through the RMM. We build that only for a short, named list of scripts your team has already been running by hand, such as restarting the print spooler on the user’s own machine. The bot can run them only against the verified user’s own device, every run is logged to the ticket, and anything that fails falls back to a technician.

A second list is off-limits for automation no matter how routine it looks: servers, firewalls, backup restores, license changes, and any security report. When a user writes “I think I clicked a bad link” or “my email sent messages I didn’t write,” the bot does not reassure them and does not troubleshoot. It opens a security-priority ticket, tells the user exactly what your incident procedure says to do next, and alerts the on-call technician.

Paging on-call without paging for everything

An after-hours bot that escalates too eagerly burns out your on-call engineer in a month; one that escalates too rarely lets a real outage sit until morning. The rules come from your existing SLA language and your on-call runbook, not from the bot’s judgment.

Typical page-worthy conditions are a whole site offline, a server or line-of-business application down for many users, a suspected security incident, and anything reported by a contact your PSA marks as a VIP for that client. Everything else is queued with a clear message telling the user when the service desk opens and that their ticket number is waiting. The bot pages through whatever you already use, whether that is PagerDuty, Opsgenie or your PSA’s own notification rules, and includes the ticket link so the engineer does not have to hunt.

The bot never invents response times. If your agreement says something about after-hours response, it quotes that text. If it says nothing, the bot says a technician will review the ticket when the desk opens.

Wiring into ConnectWise, Autotask, HaloPSA, NinjaOne, IT Glue and Teams

We build against the tools you run: ConnectWise PSA, Autotask, HaloPSA or Syncro on the ticketing side; NinjaOne, Datto RMM or ConnectWise Automate for device data; IT Glue or Hudu for documentation; and Microsoft Teams as the most common channel for end users. A few principles apply everywhere.

1. Least-privilege API accounts. The bot’s integration user can create and update tickets and read contacts and agreements. It cannot delete records, change agreements or edit billing.
2. Test in a sandbox or a test company first. Nothing is pointed at live client boards until it has created and updated a long run of fake tickets correctly.
3. Documentation is filtered at the source. Password entries and other credential objects in your documentation platform are excluded from anything the bot can retrieve. They are not hidden by a prompt instruction; they are simply never indexed.
4. Respect rate limits. PSA and RMM APIs throttle heavy callers, so the bot caches reference data like boards and priorities instead of fetching them on every message.

Our AI agents page explains how we design tools that take actions under rules like these, and the AI integration page covers the connection work itself.

The build, from discovery to go-live

It starts with a free phone or video call with your service manager and whoever owns sales. We walk through your PSA setup, your priority matrix, your on-call rotation and how clients reach you today. Next, you export a sample of recent tickets with personal details stripped so we can see which request types dominate and which ones arrive badly described.

We then write the action tiers, the triage questions, the escalation rules and the prospect qualification flow as documents your team approves. The build follows those documents exactly, first in a sandbox, then as a pilot with one or two clients who are willing to give feedback, then across the rest of your book. Pricing arrives as a fixed-scope written quote, agreed before anyone writes code.

Checking whether it actually helps the service desk

We will not promise you a deflection percentage, because nobody can know it before seeing your ticket mix. What we set up instead is a baseline month from your existing PSA reports and a short list of measures to compare against once the bot is live:

• How often dispatchers have to re-triage a bot-created ticket, which shows whether priority and routing are right.
• Time from the user’s first message to a ticket a technician can start on.
• Reopen rates on issues the bot helped users resolve themselves.
• Satisfaction scores from the survey tool you already send.
• A weekly sample of transcripts your service manager reads, with every wrong answer turned into a fix.

If the numbers do not move, that is information too. Sometimes the right conclusion is to narrow the bot to ticket creation for a few clients rather than expand it.

Behind the work is EVOTECH IT LLC: two decades and more in business, a 5.0 rating on Google, and a Houston-area team that delivers remotely to providers nationwide. Providers who mainly do project or break-fix work, without recurring agreements, may find our page on the AI chatbot for IT service companies a closer fit.

Related services

Frequently asked questions