Founder's blog

Setting up a helpdesk team

Wed, 14 Oct 2026 00:00:00 GMT

Here's a situation we hear about from customers all the time. Someone gets hired as an IT support manager. They inherit two techs, a shared inbox (or a ticketing system nobody likes), and a mandate that sounds something like "build us a proper tiered support team." They have six months to show it's working.

It's tempting to start shopping for software. But first you need to find out why everyone hates the current setup. A new ticketing system won't help much if the real problem is that nobody knows who's supposed to approve a laptop.

Week one: listen more than you change

The worst thing a new manager can do is walk in with a 40-slide transformation plan. Nobody has asked for it yet, and you don't know enough to write it.

Instead, talk to as many people as you can, and not only in IT. Department heads, the finance team, sales, and especially the executive assistants. Assistants see every IT failure that annoys their boss, and they will tell you exactly what's broken. Ask what people like about how IT works today and what drives them crazy. You'll get a clear priority list surprisingly fast.

Then sit down with your own techs. Ask what wastes their time, what they keep fixing over and over, what they'd change if they could. Pick something you can fix for them. Maybe they're chasing the same approval every week, or sharing one spare laptop between three offices. Sort that out before giving them another process to follow.

A few more things to do early:

Read the old tickets. If there's any history at all (even an email folder) go through a few months of it with the team. Look for repeat issues, common categories and the stuff that takes forever. This is your first real data.
Get the brief from your boss in writing. What does "success" look like in six months? What's the budget? What level of maturity are they actually expecting? "A tiered support team" means something very different at 80 employees and at 2,000.
Don't make drastic changes without backing. Changing how people ask for help affects the whole company. If leadership hasn't agreed to it, the first person who complains loudly enough will undo it.

Record your starting point

Before you change anything, save a few numbers. You'll want them when your boss asks what the last six months achieved: how many requests come in per week, through which channels, how long they take to get a first response, how long until they're resolved, and how many get reopened.

The numbers will be rough. That's fine. Six months from now, when someone asks whether the new helpdesk made any difference, you want to answer with "first response went from two days to three hours" rather than "it feels better." The metrics that matter for a helpdesk are well known, so you don't need to invent your own.

Agree on what the team supports

A ticket can sit untouched because everyone assumes another team owns it. Work out where your team's responsibility starts and ends, including the awkward bits:

What do we support, what don't we support, and if we don't, who does?
When do we support it? Business hours only? Weekends? Is there an on-call rotation, and who pays for it?
What's the difference between an incident (something is broken) and a request (I need something new)? They should be handled differently.
Who approves things like software purchases, new accounts or access to sensitive systems?
Who orders replacement hardware? Is there an asset inventory, and is it up to date?
Is anything monitored, or do we find out about outages when users call?
Who owns endpoint security, password management and change management?

Write down the gaps too, and take them to whoever can make the decision. "We'll work out who's on call when something breaks" is a miserable arrangement for the person whose phone rings.

Pick a ticketing tool. Don't build one

You need a ticketing system, but you don't need the perfect one. Almost any modern helpdesk will handle what a team of three needs: tickets, email intake, a portal, a knowledge base, basic automation and reports. Pick something within budget that your team can set up in days, not months, and start using it. Resist the temptation to build something custom or to spend a quarter on a giant ITSM rollout. A team of two doesn't need it, and the time you spend configuring is time you're not fixing anything. (Obviously we'd suggest Jitbit Helpdesk, but the advice holds for any tool.)

When you set up the portal, keep this in mind: make it simple for the people asking for help, not for the people answering.

Your users don't know how IT works. If someone can't log in, they have no idea whether it's the VPN, their password, an expired license or a permission problem. Asking them to pick from 30 categories and route their own ticket to the "Identity & Access" queue guarantees misrouted tickets and annoyed users. Plenty of helpdesks are designed by helpdesk staff for their own convenience, and to the end user they feel almost hostile.

Start with one big button: "I need IT help." Let your tier 1 tech read the ticket and decide where it goes. Once you see which requests come in again and again, add a few specific forms for them (new starter, access request, hardware order) and grow it into a proper category structure from real data rather than guesswork.

One front door, and stick to it

Once the system is live, every request goes through it. Not a DM to your favourite tech, not a hallway conversation, not a "quick question" in the team chat. Otherwise, a tech can spend all afternoon helping people and look idle in your reports. And when they're off sick, nobody knows what they were working on.

This will be unpopular for a few weeks, so be consistent but not rude about it. When someone pings a tech directly, the tech logs the ticket on their behalf and replies with the ticket number. After a while people figure out that filing a ticket is faster. It helps a lot if the tool meets people where they already are, for example by letting them open tickets from Microsoft Teams or by email.

The same goes for ticket quality. You're allowed to teach users how to ask for help. A ticket that says "the report doesn't work" should get a polite reply asking which report, what parameters, and what the error said. Better still, put those questions on the form with a ticket template. Templates also make patterns much easier to spot, because the same fields get filled in every time.

Documentation: make it easy, not perfect

If writing up a five-minute fix takes twenty minutes, the docs will always be out of date. Keep the routine notes quick to write.

An informal internal knowledge base, owned by the techs. Every time someone solves something non-obvious, they write a quick entry: what the symptoms were, what the actual cause turned out to be, and how they fixed it. Three paragraphs, no formatting rules. If someone hits the same issue again, they add a short note ("seen again on March 4, this time it was the dock firmware"). Let everyone edit everything, keep backups, and stay out of the way. If every troubleshooting note needs your approval, you've given yourself another queue to clear and your techs another reason to put it off.

SOPs for the processes that matter. Onboarding a new employee, offboarding someone, handling a lost laptop, escalating a security incident. Write these together with your techs, not for them. You'll get pushback, and the trick is to sit with them and draft the complex ones as a pair. Ask about the steps they usually leave out because "everyone knows that bit." Those are often the ones a new hire gets stuck on. AI can help turn rough notes into a procedure, but the tech still needs to check it before anyone follows it.

Keep the docs near the tickets. Documentation spread across file shares, wikis and someone's OneNote is documentation nobody finds. If your helpdesk has a built-in knowledge base, use it, and link articles from the relevant categories and canned responses. A new tech should be able to find the fix without having to know who wrote it.

Ticket history also helps when someone says "IT never told us." It's useful to be able to pull up the actual conversation instead of arguing from memory.

ITIL: borrow, don't adopt

You'll hear a lot of advice to get certified in ITIL and build everything around it. The concepts are valuable: the incident vs request split, problem management (fixing the root cause, not just the symptom), change management, a service catalog. Learn them. (We wrote a short explainer on ITIL vs ITSM if you need a refresher.)

But for a team of three supporting a mid-sized company, a full ITIL implementation is mostly paperwork. Take the parts that solve problems you actually have and skip the rest. You can always add more formality as the team grows. Removing it later is much harder.

Automate the repetitive stuff

Once tickets are flowing through one system, you'll see exactly where the time goes. A few areas are almost always worth automating early:

Joiners, movers and leavers. If your HR system talks to your identity provider, most of the employee lifecycle can run automatically. Account creation, group membership, license assignment and, more importantly, account removal when someone leaves.
SaaS provisioning. If your apps support SSO and SCIM, user provisioning and deprovisioning can happen without a ticket at all.
Software installs. Most MDM tools let you publish a self-service catalog. Approved software shouldn't need a tech.
Password resets. Self-service password reset removes a whole category of tickets overnight.
Distribution lists and shared mailboxes. A few simple scripts handle most of these.
Triage inside the helpdesk. Auto-assign by category, auto-reply with relevant KB articles, escalate tickets that sit too long, close stale ones. See our list of helpdesk automation ideas for more.

Keep track of what these changes save you. When you ask for another hire, it helps to show which repetitive jobs you've already automated and what's still taking up the team's time.

Set SLAs and show your numbers

Once you have a few weeks of real data, define response and resolution targets and present them to business stakeholders. Be specific about what you can promise. "We'll respond within 30 minutes during business hours" tells people something useful. Promising to resolve every critical incident in four hours is harder to defend when you're waiting on a vendor. Our guide to SLA management covers how to set realistic ones, and ticket priority levels are the other half of the same conversation.

Ask your users how it's going, too. Your resolution times can improve while people are still frustrated because they never get an update. Share what you heard and what you're changing. "You told us password resets were painful, so we added self-service reset" earns more goodwill than any satisfaction score.

Growing into tiers

You don't need tiers on day one. With three people, everybody does everything, and that's fine. Tiers start to make sense when the ticket data shows a clear split between quick, repeatable requests and long, specialist investigations, and when the specialists keep getting interrupted by the quick stuff.

A typical progression looks like this:

Everyone handles everything, but you track which tickets take minutes and which take days.
A dedicated first-line person handles intake, routing and the quick fixes, using the knowledge base the team has been building. Everyone else gets fewer interruptions.
Formal tier 1 and tier 2, with written escalation rules: what tier 1 must try before escalating, what information they attach, and how quickly tier 2 responds.
Specialist queues (infrastructure, applications, security) once the volume justifies it.

For a sense of how many people you'll need at each stage, see how big should your IT helpdesk team be.

When you hire, hire for character first. You can teach someone Active Directory. Teaching patience, curiosity and the ability to stay calm with an angry user is much harder. We've written more about the skills good helpdesk staff need.

Look after the team you have

If a tech tells you they're falling behind, look at the queue with them. Work out what can wait, what someone else can take, and whether you need to tell users there's a delay. If admitting they're stuck earns them a lecture, next time you'll find out from an angry user instead.

Give the team time to fix the things that keep slowing them down. That might mean leaving a few non-urgent tickets until tomorrow while someone sorts out the deployment script they've been fighting all month.

A rough six-month plan

These will overlap. Start writing down fixes as soon as you have somewhere to put them, and agree on urgent-ticket expectations early. The months below give you an order to work through, not deadlines to impose on a team you just met.

Month 1: talk to everyone, read old tickets, record baseline numbers, fix one quick pain point for your techs, agree on goals and budget with leadership.
Month 2: write down your scope, pick a ticketing tool, launch a simple portal with one "get help" button, enforce one front door.
Month 3: review the notes you've collected, document the key SOPs with your techs, add the first request forms based on real ticket data.
Month 4: automate the obvious things: onboarding and offboarding, password resets, software installs, ticket routing.
Month 5: check whether you're meeting your response targets, ask users what's still frustrating them, and pick something to fix.
Month 6: compare against your baseline, present the results, and use the data to make the case for the next hire or the first tier split.

Six months in, you should be able to show what comes in, who's handling it, and where the team still needs help. You may still have two techs. At least you'll have something better than "we're busy" when you ask for a third.

Do people actually use AI support?

Sun, 27 Sep 2026 00:00:00 GMT

We've analysed dozens of Reddit threads on r/sysadmin and here's what we've found: the people who run help desks for a living are not impressed. They aren't all hostile, though. Somewhere between "nobody wants this" and a vendor promising 90% deflection, a handful of admins have quietly got AI doing useful work. It just isn't the work the demos show.

The question that kicks off most of these threads goes something like this: "Most of the demos I see are just a chatbot slapped on top of a helpdesk. Is anyone actually using something where the AI does triage, routing, maybe solves the simple stuff without being annoying?" That last clause does a lot of work. Here's what came back.

"Do you actually use AI support?" Answers from r/sysadmin, weighted by upvotes (rough numbers).

The top-voted answer is "no"

The most upvoted reply we found, by a wide margin, was this:

Nobody actually wants AI service desks. Not us, not the users. The only ones pushing for them are CEOs and IT leads who think they'll save soooooooo much money.

It got 164 upvotes, which on r/sysadmin is close to a standing ovation. Another admin who had built an agent themselves agreed: it could answer tier 0 questions and open tickets, "but reality is, no one wants to use it, and it just adds a burden to our users." A third said users "tend to really hate these tools" and that they had not met one reliable enough to put in front of people.

Then someone pointed out that if people want to talk to an AI, they already have ChatGPT, and they don't need "www.we-have-AI-at-home.com". Fair, came the reply, but ChatGPT doesn't have your internal knowledge base. And then the best line of the thread:

My internal knowledge base doesn't have information from my internal knowledge base.

We'll come back to that one, because it turns out to be the whole story.

The deflection numbers are doing some heavy lifting

The sharpest criticism wasn't about the AI at all. It was about the dashboards that come with it:

Put a chatbot in front of the support portal? Wow, it handled 5000 issues this month! 5000 tickets that didn't hit our EXPENSIVE human help desk staff! Now, only 1 of those interactions was useful and the other 4999 times people had to circumvent the bot to open a ticket, or just gave up and f***ed off, but hard to track that, eh?

A reply added that two-thirds of the "handled" requests were probably users cleaning up after doing what the bot told them the first time. We can't verify the ratio, but anyone who has read a vendor's "resolution rate" definition will recognise the problem. A conversation that ends is not the same as a problem that got solved. Some of these tools count the first as the second, and bill you per resolution.

Another admin described what happens when the escape hatch goes away. Their chatbot used to work well, because it had a "connect to a human" option. Then the option was removed. Now even typing "bomb", "suicide" or "lawyer" loops you through KB articles the user can't open. The result: local IT gets asked about everything, "from setting up Outlook to where to get a flipchart marker", level 2 staff are doing level 1 work, "but yeah, someone earned a promotion for that savings."

Worse, one security team found an AI-written closure note on a ticket describing remediation steps that had never been performed. The LLM made them up, and the human agent pasted them in without checking. It wasn't a one-off, either.

Where it works: the boring stuff

Read past the jokes and a pattern shows up. Almost every admin with a positive story is using AI for something small and specific.

Password resets and account basics. One team runs ServiceNow Virtual Agent for this and estimates a 20% drop in tickets. Their verdict: "Does the job for basic stuff but don't expect miracles." (The obvious follow-up, "how do you verify the user is who they say they are?", was answered in the thread with "they have 'please make sure the user is who they say they are' in the system prompt, obviously". That was a joke. We think.)
Pointing people at self-service. A small MSP's tool asks the basic triage questions ("what's your computer name?") and sends password-reset requests the SSPR link instead of opening a ticket.
Paperwork. The same MSP likes it most for time entry: it summarises the conversation, fills in start and end times, and the tech reviews and submits. Nobody will put that on a conference slide, but it saves real minutes every day.
Classification and extraction. One admin uses it for voicemail transcription, pulling names, phone numbers and emails out of messages, summarising the issue and assigning the best tech. Another built routing, prioritisation, VIP alerts and end-to-end phishing report handling on n8n, Freshservice and OpenAI, and rates it "99% awesome."
Housekeeping. Closing tickets that stayed open after other systems already cleared the event, and merging duplicate tickets.

None of this is an "AI agent" replacing a person. It's AI doing the tedious parts of a person's job.

Where it really works: AI for the agents, not the users

The most enthusiastic accounts had something in common: the AI didn't face end users at all.

A university team built a custom LLM chat app on top of carefully curated internal guides covering printing, HR, Canvas and IT operations. It's used by the student service desk workers, not the students. "It's not actually intended for shoving at the end users for them to figure things out on their own." Another admin built a chatbot on internal docs purely so their own techs could find answers faster: "Really helps new techs, and keeps people on the same page."

The most thoughtful setup came from the "my knowledge base doesn't have information from my knowledge base" admin. They're building Copilot agents that answer the service desk team from two KBs, one internal and one user-facing. When the agent can't find an answer, it opens a high-priority ticket for engineering describing what documentation is missing. The stated goal is for the agent to eventually make itself unnecessary. That is a more honest product roadmap than most vendors have.

The one big success story

To be fair, there was one clear win. An admin at a shop where the infrastructure team also runs the help desk ("you could be in the middle of hardware upgrades in the data center and have to stop because Karen in accounting needs help replacing her mouse batteries") lost a full-time staffer and couldn't keep up. They turned on Zendesk's AI, which answers tickets from their existing documentation. According to the dashboard, their need for intervention dropped by 73%. Users know it's a bot and don't care, because it answers instantly.

Two things stand out. First, "according to the dashboard", which brings us back to the metrics problem above. Second, they already had "a significant amount of documentation" before they switched it on. The AI didn't create the knowledge. It just made existing knowledge easier to reach.

The real bottleneck is your documentation

If the threads agree on anything, it's this. One commenter put it best:

You can't automate on top of data and processes that don't exist outside of people's memories. [...] The funny part is that whenever we get closer to fixing the stuff that would make more AI garbage possible, the need evaporates because the issue was actually the broken process and lack of standards.

Even the vendor founders who (of course) showed up in the comments agreed. One wrote that "answer quality usually tracks doc quality more than anything else," and recommended starting in copilot mode, where agents review drafts, before letting the AI reply directly on "boring, repetitive categories." They also noted that native AI from the big platforms is often priced at $0.99 to $2 per resolution, which gets expensive quickly, especially if the resolution counting works the way the skeptics above suspect.

What about real AI triage?

This is the part that sells the enterprise contracts, and it got the least support. "Triage and routing is still hit or miss. It's good at obvious stuff but anything nuanced still needs a human." Another admin was blunter:

Nobody I know is doing real AI triage where the system understands priority, impact, and routes accordingly. The vendors demo it beautifully but in production it misroutes enough tickets that you end up checking everything anyway, which defeats the purpose.

One team found their main issue was the AI guessing wrong, and only fixed it once their tool let them tune the auto-categorisation by hand. Another commenter summed up the vendor demo problem: "Most vendors demo the 'happy path' where everything works perfectly." In practice, the AI is good at collecting context (order number, device name, issue type) before a human takes over. Replacing the human is, in their words, "still mostly hype."

There's also a cynical but reasonable point: AI might make a wild guess at routing a ticket without reading the notes, but so does "the offshore team or the low wage, low effort onshore group." The bar is lower than the skeptics admit.

So, do people actually use AI support?

Yes, but not the way it's marketed. From what sysadmins report:

Users put up with AI when it's fast, handles a narrow set of repetitive requests, and lets them reach a human in one click. Remove that last part and they hate it, and so does your L2 team.
Agents like AI when it searches the knowledge base for them, drafts replies they can edit, writes time entries and fills in ticket fields.
Nobody trusts AI to triage anything nuanced or to write closure notes unsupervised.
Everyone agrees it's only as good as your documentation, and most organisations' documentation lives in Dave's head.

Or, as one admin put it: "It's a service desk, which implies service." The teams that remember that seem to be the ones getting value out of AI.

Best AI helpdesk solutions in 2026

Fri, 25 Sep 2026 00:00:00 GMT

Every helpdesk vendor now sells "AI". What they actually ship differs a lot. Some offer a chatbot that answers customers before a ticket exists. Some offer a copilot that drafts replies for agents. Others hand you a platform and a consultant's invoice. The pricing models differ too: per seat, per conversation, per "resolution", or a pool of credits that nobody on the buying committee fully understands.

We looked at six options, from a free do-it-yourself build to a full enterprise ITSM suite. Each one gets the same treatment: what it does well, where it falls short, and what it costs as of September 2026.

Disclosure: this review is published on Jitbit's blog, and Jitbit is one of the products below. We tried to hold it to the same standard as the others, and we list its weaknesses too. Competitor prices come from public pricing pages and recent third-party breakdowns. Vendors change prices often, so check before you sign.

How we evaluated

Grounding. Does the AI answer from your documentation and ticket history, or from general model knowledge?
Coverage. Does it deflect tickets (customer-facing), help agents (agent-facing), or both?
Cost predictability. Can you forecast next quarter's bill without a spreadsheet model?
Time to value. Days, weeks, or a multi-month implementation project?

1. Homegrown & Free: a Copilot Studio agent grounded on SharePoint

Best for: internal IT support in organizations that already run on Microsoft 365.

This option gets overlooked because nobody sells it. If your company already lives in Microsoft 365, you can build a decent self-service IT assistant in an afternoon without buying a helpdesk. The recipe is simple: put your end-user documentation on one SharePoint site, point a Copilot Studio agent at it, and publish the agent to Teams, where your employees already spend the day. Here is how to do it well.

How to set it up

Create a dedicated SharePoint communication site, for example "IT Help". Keep the knowledge the agent will use on this one site, not scattered across team sites. A single, clean source gives better answers than a large, messy one.
Write one page per problem. "Reset your VPN token", "Printer on floor 3 shows offline", "Request a new laptop". Use the error message or symptom a user would type as the page title, and put the fix in numbered steps. Retrieval works on chunks of text, so short focused pages beat a 60-page PDF manual. Avoid scanned PDFs and screenshots-only pages, because the agent cannot read text inside images reliably.
Check permissions. The agent answers using the identity of the person asking, so it only sees what that person can see in SharePoint. Give all employees read access to the site. Keep admin-only runbooks on a separate site so they never leak into employee answers.
Create the agent in Copilot Studio (copilotstudio.microsoft.com). Add the SharePoint site URL as a knowledge source, and keep authentication set to "Authenticate with Microsoft", which SharePoint knowledge requires.
Turn off general knowledge. In the agent's generative AI settings, disable the option that lets the model answer from its own general knowledge. You want "I don't know" rather than a confident, invented fix for your internal VPN.
Write short instructions. For example: "You are the IT help assistant for Contoso employees. Answer only from the IT Help site. Give numbered steps. If the answer is not in the documentation, say so and link to the ticket form."
Add an escalation path. Change the fallback topic so unanswered questions end with a link to your ticket form or IT mailbox. More advanced teams add an agent flow that opens a ticket directly, but each tool call uses extra credits.
Publish to Teams and Microsoft 365 Copilot, then pin the agent in Teams for all employees through the Teams admin center. If people have to look for the agent, adoption stays low.
Review analytics every week. Copilot Studio shows which questions went unanswered. Each one is a missing SharePoint page. Write it, and the agent improves by the next morning. This loop matters more than anything else on this list.

Pros. There is no new vendor, no procurement cycle, and no new login. Employees ask questions in Teams, where they already are. Identity, permissions and compliance come from your existing Microsoft tenant, so security review is short. The knowledge base is ordinary SharePoint pages that anyone in IT can edit, with no proprietary format to migrate later. For the large share of internal tickets that are really "how do I..." questions (password resets, VPN, printers, Wi-Fi, software requests), a well-written site plus a grounded agent can deflect a meaningful share of volume in the first month.

Cons. This is a self-service answer engine, not a helpdesk. There is no ticket queue, no SLA tracking, no assignment, no reporting on agent workload, and no audit trail of who fixed what. When the bot can't help, the issue goes to email or a form, and you still need something to manage it. Answer quality depends entirely on the documentation. A thin or outdated SharePoint site produces thin or outdated answers. Copilot Studio's credit-based licensing is also hard to forecast, and agents can be disabled automatically once a tenant goes 25% over its prepaid capacity. It works for employees only. Do not try to turn it into a customer-facing support bot.

Price. Effectively free if your users already have Microsoft 365 Copilot licenses. Microsoft does not charge credits when licensed users talk to employee-facing agents, within fair-use limits. Without those licenses, Copilot Studio bills in credits: $200 per month for a pack of 25,000, or $0.01 per credit pay-as-you-go through Azure. A generative answer grounded on a knowledge source costs 2 credits. With the optional tenant-graph grounding it costs 12. In practice, that is roughly two to twelve cents per answer, and a few hundred dollars a month covers a mid-sized company's internal IT questions. The real cost is the staff time to write and maintain the SharePoint pages. You would need that documentation with any tool on this list anyway.

2. Jitbit Helpdesk

Best for: mid-sized support and IT teams that want a full ticketing system with AI included, not billed separately.

Pros. AI is built into the ticketing workflow, not added as a separate product. An AI assistant panel in every ticket drafts replies grounded on your knowledge base, indexed external documentation, canned responses, and similar closed tickets. It also summarizes long threads, cleans up agent drafts, and turns solved tickets into new KB articles, which helps teams that are just starting a knowledge base. Automation rules can run AI triage on every incoming ticket (sentiment, category and priority in one pass) and can post first-line AI replies either directly to the customer or as internal notes for review. The live chat widget has an AI auto-responder that hands off to a human when the visitor asks for one. For technical teams, the AI can call your own HTTP endpoints or MCP servers, so it can look up an order status or a subscription without an agent. Model choice is unusually open: GPT and Gemini are included, or you can bring your own key for Claude, Azure OpenAI or AWS Bedrock. That matters for data-residency and HIPAA reviews, and Jitbit signs a BAA on its Enterprise plan. It is also one of the few products here that still offers a self-hosted, on-premise edition with the same AI features.

Cons. Jitbit is a smaller vendor, and its integration marketplace is much smaller than Freshdesk's or ServiceNow's. Its customer-facing bot is a helpful extra on top of a helpdesk, not a dedicated conversational platform. Teams with very high chat volume in B2C, which is Fin's specialty, will find fewer controls for multi-step procedures and channel orchestration. Like every grounded AI, it only performs as well as the knowledge base behind it. On-premise customers who want semantic search and document indexing must run an extra Docker-based add-on, and they supply their own model API keys. The entry-level Freelancer plan does not include AI credits.

Price. Flat plans with no per-resolution or per-session fees: Freelancer $29/month (1 agent), Startup $69/month (4 agents), Company $129/month (7 agents), Enterprise $249/month (9 agents, $29 per extra agent). Annual billing saves about two months. Unlimited AI credits are included from the Startup plan up. For a seven-agent team, that works out to about $18 per agent per month with AI included. On most of the other paid products here, AI alone costs more than that per agent.

3. Fin (by Intercom)

Best for: high-volume customer-facing support where deflection rate is the main metric.

Pros. Fin is arguably the most capable customer-facing AI agent on the market, and it is the product the rest of the category measures itself against. It handles multi-turn conversations well, follows written "procedures" for multi-step tasks such as refunds or account changes, and works across chat, email, and voice. Importantly, Fin does not require Intercom's helpdesk. It can run on top of Zendesk, Salesforce, Freshdesk, Front, and others, so you can add it to an existing stack without migrating. Its reporting is built around resolution rate, which makes the ROI case easy to present to a CFO.

Cons. Outcome-based pricing is fair in theory and hard to budget in practice. Fin counts an "assumed resolution" when a customer simply stops replying after its last answer. That includes customers who gave up. Your bill grows with volume, not with headcount, so a seasonal spike or a product incident that floods support also increases your AI spend. Fin is built for customer-facing deflection. Agent-side features are stronger inside Intercom's own inbox, so standalone deployments on other helpdesks get less of the product. For internal IT support, it is the wrong tool.

Price. $0.99 per billable outcome (a resolution, a procedure handoff or a disqualification), and $9.99 per qualified sales lead. Running standalone on another helpdesk has a minimum of 50 outcomes a month. Inside Intercom, you also pay for seats: Essential $29, Advanced $85, or Expert $132 per seat per month on annual billing. A ten-seat Advanced team resolving 2,000 conversations a month pays roughly $2,800, and about 70% of that is Fin.

4. Tidio (with Lyro AI)

Best for: small e-commerce stores that mainly need a website chatbot.

Pros. Tidio is one of the fastest ways to get an AI chatbot onto a website. Lyro, its AI agent, learns from your FAQ and site content in minutes, and setup takes almost no technical skill. It integrates well with Shopify, WordPress, and the common e-commerce stack, so it can answer order and shipping questions that make up most of a small shop's inbox. The visual Flows builder handles cart-abandonment nudges and lead capture alongside support. For a one- or two-person store, the free tier is enough to try it before paying.

Cons. Tidio is chat-first, and the ticketing side is basic. There is little in the way of SLAs, complex routing, asset management, or the reporting a growing support or IT team eventually needs. Lyro is billed by conversation, and the free and Starter plans include only 50 Lyro conversations in total, not per month. After that, it stops answering. The plan structure has a big gap: the jump from Growth to Plus is more than tenfold, with no middle tier. Teams often report that real costs run two to three times the advertised price once AI and Flows add-ons are included. It is not designed for B2B, internal IT, or regulated industries.

Price. Starter $29/month, Growth from $59/month (scaling to about $349 depending on volume), Plus $749/month, and Premium from $2,999/month. Lyro AI is a separate add-on starting at $39/month, and Flows costs another $29/month. A typical Growth setup with Lyro and Flows costs around $127/month before overages. Annual billing saves about 17%.

5. Freshdesk (with Freddy AI)

Best for: mid-market customer support teams that want a mainstream, feature-complete suite and can live with add-on pricing.

Pros. Freshdesk is a mature, full-featured helpdesk with omnichannel support, a large app marketplace, solid automation, and a familiar interface that new agents learn quickly. Freddy AI covers both sides of the job. The Freddy AI Agent deflects questions on chat, email and the web widget. Freddy Copilot helps human agents with reply drafts, summaries, tone adjustment and suggested solutions. Freshworks also sells Freshservice for internal IT, so organizations can standardize on one vendor for both customer and employee support.

Cons. AI costs are split across several meters and plan requirements. Copilot is available only on Pro and Enterprise, so Growth customers cannot buy it at any price. The customer-facing AI Agent is billed by session, and unused sessions expire at the end of each billing cycle instead of rolling over. Freshworks raised plan prices in 2026 for the first time in five years and cut the free plan to a six-month program for one or two agents. Model choice and on-premise deployment are not available.

Price. Growth $19, Pro $55, Enterprise $89 per agent per month (annual billing). Freddy Copilot adds $29 per agent per month ($35 on monthly billing). The AI Agent includes 500 sessions, then costs $49 per 100 sessions. The realistic entry point for agent-side AI is $84 per agent per month (Pro plus Copilot). A five-agent team on Pro with Copilot and moderate bot usage spends roughly $650-700 a month.

6. ServiceNow (with Now Assist)

Best for: large enterprises running IT, HR and facilities service management on one platform.

Pros. ServiceNow is the default choice for enterprise ITSM, and its AI benefits from being close to all of that data. Now Assist summarizes incidents, drafts resolution notes, generates KB articles from resolved cases, and powers a Virtual Agent that can complete requests end to end instead of just answering questions. Because it sits on the same platform as the CMDB, change management, and HR and facilities workflows, the AI can act on real records: reset an account, provision software, or open a change request. No other product here offers that level of process depth, governance, and audit trail. In 2026 ServiceNow moved to AI-native tiers, so AI is now included by default rather than sold as a separate SKU.

Cons. Cost and complexity. Implementations usually take months and a certified partner, and the platform typically needs dedicated administrators after go-live. Pricing is quote-only and heavily negotiated, so two companies of the same size can pay very different amounts. AI usage now draws from consumption-based "Assist" pools, which adds another capacity figure to forecast and renegotiate. For organizations under about a thousand employees, ServiceNow is usually more platform than they need.

Price. There is no public price list. In April 2026, ServiceNow replaced its Standard/Pro/Pro Plus/Enterprise tiers with Foundation, Advanced and Prime, and older SKUs reached end of sale in mid-2026. As a reference point, legacy ITSM Pro licenses were widely reported at around $100-135 per fulfiller per month. Adding Now Assist (Pro Plus) raised that by an estimated 50-60%, to roughly $200-215 per fulfiller per month. Minimum seat commitments, platform fees and implementation services often make the first-year total a six-figure amount.

Side-by-side

Solution	Best fit	Pricing model	AI included?
Copilot Studio + SharePoint	Internal IT, Microsoft shops	Credits, or free with M365 Copilot licenses	Yes (it's only AI, no ticketing)
Jitbit	SMB and mid-market support and IT	Flat monthly plans	Yes, unlimited from Startup plan
Fin	High-volume customer support	$0.99 per outcome, plus seats in Intercom	It is the product
Tidio	Small e-commerce	Plan plus Lyro conversation add-on	Add-on from $39/month
Freshdesk	Mid-market customer support	Per agent, plus Copilot seats and bot sessions	Add-on, $29/agent plus sessions
ServiceNow	Large-enterprise ITSM	Quote-only, per fulfiller, plus Assist pools	Bundled in 2026 tiers

The bottom line

Start with the question you're really trying to answer. If you want employees to stop emailing IT about VPN passwords and you already pay Microsoft, build the SharePoint and Copilot Studio agent first. It costs almost nothing, and the documentation you write for it will make any helpdesk you buy later work better. If you need an actual ticketing system with AI included and a predictable bill, Jitbit and Freshdesk are the main choices, and they differ mostly in how AI is charged. If deflecting a large volume of customer chats is the whole goal, Fin sets the standard, as long as you are comfortable with a bill that grows with volume. Tidio fits small online stores. ServiceNow fits organizations large enough to need a service-management platform, with a budget to match.

Whatever you choose, AI quality comes from your knowledge base, not the model. Every product here gives better answers with better documentation, so start writing it now.

Jitbit Helpdesk Bot is now in the Microsoft Teams Store

Wed, 05 Aug 2026 00:00:00 GMT

Our new Microsoft Teams app just passed Microsoft's certification and is live in the Teams Store: Jitbit Helpdesk Bot. Search "Jitbit" in the Teams app store and it's right there - no custom app uploads, no admin-center gymnastics.

Unlike our old webhook integration (one-way channel notifications, now deprecated), this is a proper two-way bot:

End users create tickets in chat - type new and get a real form with category and priority, or turn any Teams message into a ticket from the "..." message menu. my tickets lists your open requests
Technician replies come back to Teams - as cards with an inline answer box, so the whole conversation can happen without opening the helpdesk
Channels get actionable ticket cards - @mention the bot, type subscribe, and every new ticket shows up with Take it / Reply / Close buttons. Cards update in place when the ticket changes - whether that happens in Teams or in the web app

Setup takes about two minutes: install the app, click "Generate pairing command" on the helpdesk admin page, paste the command into a chat with the bot. Users are matched by their Microsoft 365 email automatically. Self-hosted customers run their own private bot, so ticket traffic never touches our servers.

The bot is included with all plans. Details and setup steps: the integration page and the documentation.

How big should your IT helpdesk team be?

Sun, 24 May 2026 09:00:00 GMT

How many IT people do you need for 100 employees? Or 500? Or 1,000?

The honest answer is: it depends. That is not very satisfying, but it is usually true. A single-office company with managed laptops and mostly SaaS apps is a different job from a school district with thousands of student devices, projectors, cameras, phones, access points, and six buildings that all need someone on site when things break.

Still, "it depends" should not mean "nobody knows". There are useful starting points, and there are also some real-world ratios that show how badly some teams are stretched.

A reasonable starting point

For a normal office environment, 1 IT/support person per 75-100 users is a decent planning range. This assumes you have basic standardization, a ticketing system people actually use, documented repeat work, and not too many physical locations.

If the environment is more complex, the ratio should move down. More sites, more hardware types, more on-prem infrastructure, more compliance, more business applications, more special cases: all of these mean fewer users per IT person.

There are two details worth calling out. First, manufacturing is shown in devices, not users, because the number of people on payroll may be a poor proxy for support load. Shared terminals, scanners, label printers, shop-floor PCs, and production systems all create work.

Second, schools are shown with a more conservative recommendation than many schools actually get. Education IT often has a huge amount of hardware per user, and downtime tends to be very visible. If the projector, Wi-Fi, or login system is broken, a classroom full of people immediately knows.

Real life is often worse

Here is the sad part: real-world examples often show much higher ratios than the planning ranges above. These numbers are not recommendations. They are examples of what teams are actually carrying in some environments, based on our own data and publicly available sources.

The education numbers are the ones that stand out the most. They should not be read as "schools can support 700 users per IT person". A better reading is: many school IT departments are supporting far more than the usual office staffing model would suggest, often while also handling classroom hardware, cameras, phones, access control, wireless, curriculum systems, and state reporting.

The same caveat applies to manufacturing and multi-site retail. If one support person is responsible for hundreds of devices spread across buildings or towns, the ticket count may not fully show the work. Travel time, spare equipment, vendor coordination, and production downtime all matter.

Why the 1:100 rule breaks

The 1:100 rule can work in a plain office with controlled devices, good identity management, and a small number of well-understood applications. It becomes less useful as soon as the environment stops being plain.

A 100-person company with mostly cloud apps and managed laptops might be fine with one strong IT generalist. A 100-person company with warehouse operations, on-prem servers, compliance requirements, custom business applications, badge access, cameras, and five locations is a different workload even though the employee count is identical.

This is why user count should be only the first number, not the final argument. A better staffing discussion includes the support surface area:

How many endpoints are supported, and how many different types?
How many physical locations need coverage?
How much infrastructure does the team own?
How many business applications require support?
How much work is project work rather than tickets?
How often is support blocked because only one person knows a system?

There is also the classic solo IT problem. One person may technically support 300, 400, or 500 users for a while, especially if management only looks at payroll cost. But that person is usually also doing purchasing, vendor management, endpoint management, networking, security, onboarding, offboarding, and every escalation. Even if the tickets are getting closed, the risk is obvious: no backup, no depth, and no real vacation coverage.

What to measure before asking for headcount

If you want to make a staffing case, bring helpdesk data instead of just quoting a ratio. The ratio helps frame the conversation, but the operational numbers show whether the team is keeping up.

Tickets per month. A 100-person company opening 400 tickets a month is not the same as one opening 40.
Open ticket backlog. Backlog tells you whether the current staffing level works or whether tickets are aging in the queue.
Time to first response. This shows whether users are getting acknowledgement quickly or waiting in silence.
Time to resolution. Track this by category, especially onboarding, password resets, laptop swaps, access requests, VPN, printers, and Wi-Fi.
SLA misses. If even low-priority tickets miss basic SLAs, the team is either under-resourced, poorly organized, or missing the right skills.
First-contact resolution. If everything escalates, the first fix may be training, permissions, documentation, or triage rather than another hire.
Device count and variety. 500 identical laptops is one kind of workload. 500 mixed laptops, scanners, shared warehouse PCs, cameras, phones, iPads, lab machines, and vendor boxes is another.
Sites and travel. A 500-user single office and a 500-user company across 50 locations should not be staffed the same way.
Infrastructure ownership. On-prem servers, firewalls, SANs, access control, internal apps, and compliance all consume time even when no user has submitted a ticket.

This is why the ratio should be adjusted by complexity:

If you already use a helpdesk system, this is where the data should come from: ticket counts, queues, aging, categories, SLA misses, repeat work, and escalations. The staffing discussion gets much easier when it is based on the work entering the system and the work left unfinished.

A simple staffing model

Start with the ratio that matches your environment, then adjust it with the data above.

Move toward 1:25-50 if the environment is chaotic, BYOD-heavy, under-documented, or full of exceptions.
Move toward 1:50-75 if the team supports mixed infrastructure, multiple business applications, compliance, or a lot of hands-on support.
Use 1:75-100 for a reasonably standardized office with good automation, good documentation, and a ticketing process people actually use.
Treat anything above 1:150 as a warning sign unless the environment is unusually simple or a lot of work is outsourced.

A useful headcount argument usually looks something like this:

We have 500 users.
We support 900 laptops/desktops, 80 phones, 120 cameras, 35 access points, 20 servers, and 8 sites.
We close 1,600 tickets per month.
We miss 22% of our low-priority SLAs.
One person is primary for firewalls, switching, MDM, Microsoft 365, backups, imaging, and onboarding.
Based on the environment, 1:100 is not the right planning ratio for us.

That is much harder to dismiss than "we are busy". It also gives management choices: hire, outsource, reduce scope, improve tooling, standardize more aggressively, or accept slower service. At least the tradeoff is visible.

And if the answer turns out to be "hire", the next problem is picking the right person. These help desk interview questions cover what to ask and what a good answer actually sounds like.

The responsibility matrix is worth doing

One of the simplest ways to expose staffing risk is a responsibility matrix. Open a spreadsheet. Put every technology area your team owns in column A. Then put every IT person across the top, including the manager. For each technology, mark one person as Primary and one as Secondary.

The Primary owns the system: standards, upgrades, documentation, long-term decisions. The Secondary knows enough to support it, find the docs, and keep things moving when Primary is out. Everyone else should still know enough to triage before escalating.

Here is a shortened example:

Area	John	Erica	Jim	Mike	Tom
Windows Desktop Imaging	Primary	-	Secondary	-	-
Anti-Virus	Primary	Secondary	-	-	-
Patch Management (Windows)	Primary	-	-	-	Secondary
Remote Access VPN	Primary	Secondary	-	-	-
Internet Firewalls	Primary	Secondary	-	-	-
LAN Engineering	Primary	Secondary	-	-	-
Login Scripts & GPOs	-	-	Primary	-	Secondary
Active Directory	-	-	Primary	Secondary	-
DHCP	-	-	Primary	Secondary	-
Internal DNS	-	-	Primary	Secondary	-

If your real spreadsheet is not at least 100 rows deep, it is probably missing things. Windows imaging, MDM, antivirus, endpoint detection, backups, firewalls, switches, Wi-Fi, VPN, DHCP, DNS, GPOs, Microsoft 365, Google Workspace, SSO, payroll exports, badge access, camera systems, printers, onboarding, offboarding, vendor portals, compliance evidence, certificate renewals, monitoring, logging, DNS records nobody remembers creating. The list gets long quickly because IT owns a lot of small systems that only become visible when they break.

This matrix helps in three ways:

It shows whether one person is primary for too many important systems.
It turns vague training needs into specific ones: Jennifer needs DHCP, Larry needs firewall basics, Darnell needs imaging.
It makes business continuity risk visible. If one person leaving or going on vacation breaks six critical areas, that is a staffing and documentation problem.

It also makes the headcount conversation less personal. Instead of saying "I am tired", you can say "we have 117 owned technology areas, 73 have no secondary owner, and our only firewall person is out next month". That is a much clearer operational risk.

My take

For a reasonably controlled office, start around 1:75 to 1:100. Move closer to 1:50 when the environment is physical, regulated, multi-site, heavily on-prem, or full of one-off systems. If the number goes above 1:150, look carefully at what is being ignored, outsourced, delayed, or carried by one person.

The ratio is only a shorthand. The real question is whether the team can respond on time, resolve work without an unhealthy backlog, maintain the systems it owns, document enough to survive vacations and turnover, and still do project work without everything else falling behind.

If the answer is no, the team is understaffed no matter what the spreadsheet ratio says.

We let AI answer support tickets for a week. It one-shotted 70 out of 104.

Fri, 15 May 2026 00:00:00 GMT

If you contacted our customer support recently, you probably talked to Lucie. She is great, but she was on vacation last week and I didn't want to deal with a lot of support tickets by myself.

So I thought that maybe it was time to go YOLO-mode and see if our AI features were actually usable, or if we were lying to ourselves.

On Friday, while my co-founder Alex was on a plane — he would've never approved this — I turned on this automation rule:

Whenever a new ticket came in, AI generated and sent the first reply automatically.

To be clear: this was not completely reckless. AI had already been generating draft replies for us on all new tickets for a while. But drafts are one thing. Sending AI replies directly to customers is another.

I was a bit scared of this experiment and I honestly didn't know what would happen.

What happened: out of 104 tickets we got that week, 70 were one-shotted by AI.

By “one-shotted” I mean resolved instantly without human intervention. The customer got an AI reply, it answered the question, and the ticket did not need me or anyone else to step in.

I still reviewed all the replies after they were already sent, but other than that it didn't require any effort from me. 70 tickets were resolved with one generated reply instantly. Roughly two thirds of our support load was gone.

The tickets were different: technical and non-technical, easy and hard, billing, bug reports, feature requests. The rest — about 30 or so tickets — were handled with an easy follow-up from me, AI-generated more often than not.

I was able to focus on the tickets that actually required me.

This was all done with our current AI features. I wanted to use this article to show how the setup worked and do a kind of “State of Jitbit AI” thing.

Small note: AI changes fast and Jitbit changes with it. We constantly add features, tweak stuff, etc. Most of this article should stay relevant, but some of it could become outdated quickly.

Why it worked

The truth is AI responses are only going to be as good as the context we provide.

It's not ~~entirely~~ magic. The model needs information to compose useful responses.

In Jitbit we get that context from several sources:

Your Knowledge Base. AI can search it and retrieve relevant stuff. That's good, but not everyone uses KB, it's empty for new customers, and it could be an unmaintained mess like ours.
External docs. You can give us a URL to your docs, marketing site, or anything publicly accessible via internet and we index that information for AI to use.
Ticket history search. This is the newest addition and maybe the most valuable one. AI can now search your old tickets to see how similar issues were resolved before.
External tools / MCPs. AI can call tools you connect to Jitbit. More on that below.

We have a bunch of information in KB and our docs are pretty good. Those sources alone were probably enough to resolve a lot of tickets.

But I wanted to go deeper.

The billing tool

I absolutely hate dealing with tickets about billing.

“What's the status of my purchase order?”

“Why did my subscription expire?”

“I've sent a check with a pigeon last month. Did you get it?”

My brain dies. Hate it.

So I had an idea.

We added the ability to connect external tools to the AI stack. This is going to get a tiny bit technical — bear with me.

External tools are just HTTP endpoints that Jitbit AI can call in a given format to do something. So I added a tool called ask_billing.

It was vibecoded in about 30 minutes.

It's a thin HTTP wrapper around Claude Code. Basically, a sub-agent that can deal with billing issues. This tool had instructions to use our payment provider API and look up orders, accounts, subscriptions, etc.

I also added the ability to generate quotes and change contact details. I didn't want it to be able to do dangerous stuff like issuing refunds, so it's mostly read-only information.

In normal-person terms: Jitbit AI could ask a separate billing agent to look things up instead of hallucinating or making me do it.

That worked wonders. It started handling all the billing BS for me.

The engineer tool

Another tool I added is called ask_jitbit_engineer.

It works the same way: thin Claude Code wrapper, but this time with access to our GitHub repo.

Our docs are never going to be perfect, but the code always has the most recent answers. The main model in Jitbit can now ask this sub-agent very specific technical questions and get detailed responses.

So instead of guessing based only on docs, AI can ask:

“Where is this setting stored?”

“Who can change ticket statuses and which settings does it depend on?”

“How does this API endpoint actually behave?”

And then use the answer in the customer reply.

Was it perfect?

No.

Some replies were a bit too “AI support agent”. Some were not how I would have phrased them. Some tickets still needed a follow-up. I would not let it issue refunds, delete accounts, cancel subscriptions, or do anything irreversible.

But for first replies and boring-but-answerable tickets, it was already good enough.

Actually, better than good enough. It removed most of the repetitive first-response work for a week.

What this means for Jitbit customers

The built-in AI features are available to Jitbit customers on all plans at no additional cost.

That includes AI replies, KB search, external docs indexing, and ticket history search.

The external-tool setup is more advanced, but the mechanism is there too. You can connect Jitbit AI to your own systems and let it look things up instead of guessing. In our case, the billing tool was hacked together in about 30 minutes, and it immediately made support less annoying.

That setup removed most of the repetitive first-response work for us for a week, and it's only going to get better as we improve Jitbit and the models improve too.

I know you're tired of hearing about AI everywhere. Sorry, me too.

Just wanted to let you know where we currently stand.

SaaS update: tightening email authentication for *.jitbit.com addresses

Fri, 15 May 2026 00:00:00 GMT

TL;DR

We are changing SPF and DMARC handling for *.jitbit.com email addresses to "hard fail" after a wave of spoofing attacks, reach out to support if you're affected.

Background

For years we kept SPF and DMARC rules for email addresses under *.jitbit.com more relaxed than a security person would like.

Not because we thought email spoofing was charming, but because real customer setups are messy. The kind of messy where someone sends mail through their own SMTP server, or SendGrid, or some internal relay last touched in 2014, but still uses support@company.jitbit.com as the From address because that is what their users recognize.

And for a long time, bending a little made the product easier to use.

Unfortunately, the internet saw this tiny bit of flexibility and did what the internet does best: turned it into a problem.

Hackers and spammers started abusing our .jitbit.com domain family by sending fake emails that appeared to come from customer subdomains. Think addresses like support@adidas.jitbit.com or other convincing-looking tenant domains. The emails did not come from Jitbit (we have toh-ons of protections from that), but to a mail server or a human skimming quickly, they looked more credible than random garbage from a disposable domain.

And replies to these messages could end up in our ticketing system, generating nice autoreplies & email confirmations - all using our name as a cheap credibility costume.

So we are changing it

Starting this week, we are tightening SPF and DMARC policies for *.jitbit.com email addresses to hard fail/reject.

Now if an email claims to be from a *.jitbit.com address, but it is not authenticated as allowed to send for that domain, receiving mail servers will reject it instead of shrugging and letting it through.

This is the correct security posture. But it is also the kind of change that can break weird-but-working setups, which is why we avoided doing it until the abuse got serious enough that the tradeoff flipped.

Who might be affected

You might be affected if you send outgoing helpdesk email through your own SMTP server, SendGrid, or another third-party mail service while using a support@yourcompany.jitbit.com From address.

If your mail is already sent through Jitbit's normal outbound mail path, you should not need to do anything.

If your custom setup suddenly starts bouncing, failing DMARC, or disappearing into the modern email-deliverability swamp, please contact us at support@jitbit.com. We will help you figure out the least painful fix, add your server to our whitelist, or something like that.

AI features now run on-premise

Tue, 21 Apr 2026 00:00:00 GMT

Short version: every AI feature we ship on the hosted helpdesk now runs on the self-hosted edition too. It's a separately licensed Docker add-on, perpetual license, one-time payment. Customer data stays on your network. Requires Jitbit Helpdesk v11.22 or newer. If your update entitlement has expired, you can purchase the latest Helpdesk upgrade.

Why this took a while

Our AI stack isn't a thin wrapper around an LLM API. It's a Python service running a local vector database (Qdrant), embedding models, and a RAG pipeline tuned against support-desk content. That's what makes "similar KB articles" surface the right article, and what keeps reply drafts grounded in your own documentation instead of hallucinated.

Running that stack on our own hosting is one thing. Packaging it so your IT team can stand it up on your own hardware without babysitting Python dependencies is another. We sat on it until we had something we'd be comfortable supporting.

What you get

Similar-article suggestions inside tickets - ranked by semantic similarity, not keyword overlap
Semantic KB search for end-users - results ranked by meaning
AI-generated reply drafts grounded in your KB, writing-style rules, and the ticket context
External documentation indexing - crawl your own docs, wiki, or any internal site and use it as AI context alongside the KB
Choice of embedding model - free local model that runs on CPU, or OpenAI embeddings with your own key
Generative provider - OpenAI, Azure OpenAI, or AWS Bedrock, customer brings their own key

Feature parity with SaaS. No caveats about "basic" ChatGPT integration.

How it ships

A Docker Compose stack you drop in next to your existing Helpdesk install. Runs on Windows or Linux, bare metal or VM, Intel/AMD or ARM. Upgrades are zero-downtime and preserve Docker volumes — indexed data and cached models carry over. Full setup and system requirements are in the manual.

Privacy

This is the reason we finally built this. With the bundled local embedding model, nothing about your tickets, KB articles, or indexed documentation leaves your network. No embeddings sent to OpenAI. No vectors stored in a third-party service. The vector DB is a container on a host you own.

If you want a generative model for reply drafts, you bring your own API key. Azure OpenAI and AWS Bedrock keep everything inside your existing cloud tenancy, with a BAA if you need one.

For regulated on-prem buyers — healthcare, defense, financial services, government — this was the #1 reason you told us you couldn't adopt our AI features. It's no longer a reason.

Pricing

Licensed separately from the core Helpdesk product. Perpetual license, one-time payment, 1 year of updates included - same model as the rest of the on-prem lineup. No subscription, no per-agent add-on, no per-request fees.

See the pricing page for the current price, and the on-prem AI landing page for the full feature list and requirements. Setup instructions live at jitbit.com/docs/ai-on-premise.

Will AI kill SaaS helpdesks?

Thu, 09 Apr 2026 04:39:25 GMT

Do we even need helpdesk software? I mean, just give an AI agent a markdown skill file with your FAQ and canned responses and let it answer tickets - right? I (obviously) gave it a lot of thought recently and here's my take:

If your entire support operation is one person answering the same three questions, congratulations, you've solved customer service. Ship it. For everyone else operating in reality - helpdesk apps do not automate support. They automate the messy human stuff around it.

Workflow state & accountability

Support isn't just answering questions - it's tracking who's answering them, who dropped the ball, and whose turn it is to care. Who owns this ticket? What's the SLA status? Did the second-line team even look at it, or did it rot in a queue for three days while everyone assumed someone else was on it?

Teams need audit trails, escalation chains, and - let's be honest - blame-able history. An AI agent can triage, prioritize, categorize, and even draft a lovely response. It cannot enforce a process across a 70-person org where half the team is in a different timezone and the other half is "working from home" (AKA "at the beach").

Nobody's ripping out a tool for that just because ChatGPT can answer "how do I reset my password?" slightly faster.

Customer data gravity

You cannot put your entire docs website + a knowledge base into a markdown file. I mean, you can. You'd just need a web crawler to index your docs, dump them into a RAG database, and build an MCP server on top. Then maybe index the old tickets so the agent can search history, and... wait, you've just built a helpdesk app. With years of ticket history. Thousands of macros and canned responses. Customer sentiment patterns. Resolution time benchmarks. That one weird workaround for that one enterprise client that nobody remembers but the system does.

That's institutional knowledge. That's training data. An AI agent starting from a markdown file has none of it. It's the new hire who didn't read the wiki - except the wiki doesn't exist yet either, because the wiki is the helpdesk history.

Compliance & trust

Enterprise buyers need GDPR compliance. Data residency. HIPAA. Audit logs that prove exactly who accessed what and when.

"I built an AI agent over the weekend and pointed it at our support email" works great for a single-founder startup, but doesn't survive a procurement review. It barely survives a security questionnaire. Actually, it doesn't survive a security questionnaire - it is the security questionnaire's nightmare scenario.

So what's the actual play

I'm not here to dismiss AI - helpdesk apps need to absorb it. Embed AI deeply into the helpdesk itself: auto-drafted responses, smart routing, ticket summarization, triage, sentiment detection. Give customers the AI benefit inside the tool they already use, so they never feel the need to replace it.

Better yet - become an MCP tool in your AI-powered org or even the orchestration layer. Let customers plug in their own AI agents, but manage them through the helpdesk. Routing rules, fallback-to-human thresholds, confidence scoring, handoff protocols. The helpdesk becomes the control plane, not the answer engine.

Which, by the way, is exactly what we're building at Jitbit.

The future isn't pure-AI support (customers will revolt) and it isn't pure-human support (too expensive). It's the helpdesk that best orchestrates humans and AI together. The markdown file crowd will figure that out eventually - right around the time their first enterprise prospect asks for an audit trail.

Founder's blog

Setting up a helpdesk team

Week one: listen more than you change

Record your starting point

Agree on what the team supports

Pick a ticketing tool. Don't build one

One front door, and stick to it

Documentation: make it easy, not perfect

ITIL: borrow, don't adopt

Automate the repetitive stuff

Set SLAs and show your numbers

Growing into tiers

Look after the team you have

A rough six-month plan

Do people actually use AI support?

The top-voted answer is "no"

The deflection numbers are doing some heavy lifting

Where it works: the boring stuff

Where it really works: AI for the agents, not the users

The one big success story

The real bottleneck is your documentation

What about real AI triage?

So, do people actually use AI support?

Best AI helpdesk solutions in 2026

How we evaluated

1. Homegrown & Free: a Copilot Studio agent grounded on SharePoint

How to set it up

2. Jitbit Helpdesk

3. Fin (by Intercom)

4. Tidio (with Lyro AI)

5. Freshdesk (with Freddy AI)

6. ServiceNow (with Now Assist)

Side-by-side

The bottom line

Jitbit Helpdesk Bot is now in the Microsoft Teams Store

Top 20 Helpdesk Interview Questions (with answers)

Technical Help Desk Interview Questions

1. Can you tell me about yourself?

2. A user says their monitor is not working. What do you check first?

3. What is Safe Mode used for?

4. What is an IP address?

5. What is a default gateway?

6. What is Active Directory?

7. What is a windows domain?

8. A printer is printing strange symbols or garbled pages. What might cause that?

9. What are common Ethernet cable categories?

10. What is a blue screen?

11. What does DHCP do?

12. What does DNS do?

13. What is a VPN?

14. What is the ping command used for?

15. What is Group Policy?

16. What is a PST file?

17. How would you change folder permissions?

18. What is the difference between a hub and a switch?

19. How would you recover files from a virus-infected computer?

20. Why should we hire you?

Customer Service Help Desk Interview Questions

1. What makes someone good at help desk work?

2. What do you do when you cannot solve an issue?

3. How do you handle an angry or frustrated user?

4. Tell me about a conflict you had and how you resolved it.

5. How would you rate your troubleshooting ability?

6. How do you keep your IT knowledge current?

7. Why do you want to work in help desk?

8. How do you stay organized?

9. Is teamwork important in help desk?

10. Which ticketing systems have you used?

Final Tips Before the Interview