All articles

Customer Support

Can AI take over your internal IT helpdesk?

The internal IT helpdesk is an easier automation target than customer support — known requesters, repeating request types, systems you own — and a riskier one, because the agent can act. Where the line between answering and acting belongs.

5 min read50–70%realistic target on the ticket channel
On this page

AI can take over the repeatable part of your internal IT helpdesk, and that part is usually larger than in customer support: internal requests concentrate into a handful of categories, the requester is already known to your directory, and the systems holding the answers are ones you control. On the email and ticket channel, a realistic target is the same 50–70% we contract for customer support — measured on your tickets, not promised from a demo.

What makes internal support different is not the language understanding. It is authorisation: the moment an agent can do things rather than say things, the design question becomes who is allowed to ask for what.

How is internal support different from customer support?

Five differences that change the design:

  • You know who is asking. Every requester is in your directory, with a role, a department and an entitlement set. Customer support has to establish identity first; internal support starts with it.
  • The request types concentrate. A handful of categories — access, accounts, devices, software, connectivity — usually cover most of the queue, which is exactly the shape automation likes.
  • The systems of record are yours. Identity provider, ITSM, asset inventory, internal documentation: you own the APIs and the data, so an agent can actually check things instead of guessing.
  • The cost of a slow answer is internal, not commercial. Nobody churns because a laptop request waited two days — the loss is quieter: people blocked, workarounds, shadow IT.
  • Authorisation is the hard part. In customer support the risk of a bad answer is a bad experience. Internally, a bad action can hand someone access they should not have.

The engine is the same one that runs customer support: read the request, classify it, enrich it from the systems of record, route or resolve, escalate what it is unsure about. Pointing it inward changes the sources and the permission model, not the architecture.

Which internal requests actually repeat?

In most mid-size companies, the recurring queue looks like this:

  • Access and permission requests — a system, a shared folder, a licence seat.
  • Account and credential issues — lockouts, MFA re-enrolment, expired passwords.
  • Software installs, licence assignments and version questions.
  • Connectivity — VPN, printers, meeting rooms, the recurring network complaints.
  • Onboarding and offboarding checklists, which are pure process and rarely fully followed by hand.
  • "Where is the document / who approves this / what is the policy" — questions whose answers exist but are hard to find.

You do not have to guess your mix. Export last quarter's tickets, group them by type, and look at the top ten. If those ten cover more than half the volume, the case is already there before anyone builds anything.

Where is the line between answering and acting?

This is the part security will ask about, and they should. Five rules we hold to:

  • Read-only answers can be fully automated. Looking something up, explaining a policy, checking a request's status — no approval needed.
  • Actions execute only from a pre-approved catalogue. The agent picks from a list of operations engineering defined; it never invents an operation.
  • Entitlement is checked against the directory, not inferred from the request. "I need admin on this" is a claim, not an authorisation.
  • Privileged operations keep a human approval step. One click from the owner, with the context attached — fast, but not automatic.
  • Everything is logged. Who asked, what the agent decided, which source it used, what it executed. Without this you cannot audit it, and if you cannot audit it, security is right to block it.

Under these rules the automation rate is lower than a vendor deck would suggest, and the system survives its first security review. That trade is worth making every time.

What does it cost, and what do you get?

The price follows the line drawn above — what the agent is allowed to do, not the fact that it is a helpdesk. An agent that answers, looks things up and drafts replies, read-only against your systems, is a Spinner: from €2,500 / $2,900 for the build, plus a €200–300/month maintenance fee on top. The moment it acts — resets, access grants, anything from the pre-approved catalogue — there are integrations to build and a critical process to supervise, and that is a Bottlenose: from €5,000 / $5,900 plus a €300–700/month fee, with privileged operations kept behind human approval. The scope is written down before anyone builds: it comes out of a free 30-minute intro call, where we place your queue on the answering/acting line.

NumberWhat it measures
50–70%realistic target on the email and ticket channel
from €2,500 · $2,900Spinner — answers and drafts, read-only
from €5,000 · $5,900Bottlenose — the agent acts, supervised
24/7first response for internal requests

What stops these projects from working?

Undocumented process is the usual blocker. If the real answer to a recurring request lives in one person's head and nowhere else, an agent cannot retrieve it. The fix is not a bigger model; it is writing the answer down once. Automation projects that go well often start by turning ten tribal answers into ten short internal documents.

The other blocker is scope creep dressed as ambition — the plan that starts with the ticket channel and quietly grows into an identity migration. We keep the boundary contractual: one channel, defined systems, everything else quoted separately once it has been priced.

What is your IT queue made of?

Run the free AI Audit — five minutes, and you get a read on how ready your internal support is and which requests to automate first. Then book a call and send us your top ten request types: we will tell you which ones need a document, not a model. Where the data sits is covered on Security & Data.

Questions people ask us about this

Should we start with a Slack or Teams bot?

Usually not first. Start where the requests already arrive — the ticket system and the IT mailbox — because that is where the volume, the history and the measurable baseline are. A chat entry point is a good second step once the resolution logic is proven; building it first means launching an interface with nothing behind it.

Can it reset passwords or grant access on its own?

It can execute operations you have pre-approved, against entitlements checked in your identity provider, with every action logged. Anything privileged keeps a human approval step. An agent that decides for itself who deserves access is not an automation project, it is an incident waiting to be written up.

Does this require handing internal data to an outside AI provider?

No. The same architecture runs inside your own cloud — your accounts, your region, your access controls — so tickets, documents and directory data stay where they already are. That is often the deciding factor for internal support, where the content is employee data by definition.

The build that does thisEmail-to-Ticket AutomationCustomer Support Automation · delivered in weeks