More from Founder's blog
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.
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.
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.
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. 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.
More in programming
This post was previously published through my newsletter on October 19, 2026. From time to time, I will republish newsletter issues on my blog here if I think people (and search engines) might benefit from it. If you want to read everything I’ve written once it is posted, I recommend signing up for the newsletter. For the last 5-6 years or so, I’ve been talking about, teaching and helping teams implement contract testing on a regular basis. To make that more concrete: at the moment, I’m having ongoing conversations with four different potential clients about helping them in some way with their contract testing implementation, and so far, I’ve run my contract testing workshop four times this year. It probably doesn’t come as a surprise to you when I say that I really like the concept of contract testing as a means of addressing integration testing challenges in distributed software systems. However, no matter if I’m speaking, teaching or implementing contract testing, certain challenges almost always come up at some point, and I want to highlight some of those today. Understanding the concept of contract testing First of all, it often takes people a while to understand the concept of contract testing, especially when they’re used to what I call the ‘traditional’ approach to integration testing: deploying the systems and services in scope to a shared testing environment and then testing them ‘as a whole’. Of course, the more distributed your system and your development process is, and the higher the deployment frequency, the more complex and the slower this integration testing approach is going to be. The premise behind contract testing is to break that integration testing puzzle down into small chunks of individual consumer-provider pairs, and then test the integration between those two in an asynchronous manner. By asynchronous, I mean that there is no need to deploy consumer and provider into a shared environment; both parties perform their part of the process in their own, local development environment. This means you can detect potential integration issues before you deploy, instead of stumbling onto them after you do so. This makes contract testing (or contract-based integration testing, to use its proper name) a significantly different approach to integration testing compared to the more ‘traditional’ approach. In my experience, it usually takes people time to wrap their head around how the process actually works, which steps you should take and in which order, and what you (do not yet) know after each step. It often takes going through several contract testing cycles before people start to ‘get it’. That’s not their fault, that is to be expected, since the contract-based approach to integration testing is, again, quite different from what they’ve been doing for so long. To better cater to this, I redesigned my contract testing workshop a year and a half or so ago. It is now a full-day workshop (half a day is simply too short), and I take much smaller steps and repeat them more often. From what I see, this has led to a better understanding of the concepts with my audience, and that’s the whole point. Contract testing === Pact I’ve talked to quite a few teams that had heard of contract testing somewhere, decided that that was the way out of their integration testing problems, and then immediately started writing contract tests with Pact. Understandable, because Pact is a very useful, very powerful and very popular tool, plus, it’s open source, which makes it easy for teams to get started. Often, they skipped a step in the process. Pact is very much a consumer-driven contract testing tool by nature, and while consumer-driven contract testing is the richest and most powerful of the different approaches to contract testing, it is not necessarily the best fit for every team and every context. It’s a classic example of using the wrong tool for the problem at hand, because they didn’t take enough time looking at the problem and the available solutions. That’s not the problem of Pact, even though it is often framed that way (‘Pact didn’t solve my problems, therefore Pact is not a good tool’). That’s a ‘we didn’t fully understand the problem and the context’ problem. Contract testing removes the need for communication Another challenge that I often see when I talk about or help teams with contract testing is the fact that teams don’t talk to each other. This then leads to integration issues, because team A expects something from team B that team B doesn’t supply. Contract testing is not the solution to these problems. It can’t be - tools alone do not solve problems, let alone communication problems. What contract testing does do is make potential integration issues visible early on in the development process, often earlier than (again) more ‘traditional’ approaches to integration testing. That’s where the value of contract testing can be found. It is not a means to replace communication between teams. In fact, and this is especially true for consumer-driven contract testing, contract testing cannot succeed without good communication between consumer and provider teams. Contract testing replaces all other types of integration testing This one comes up less often than it used to, but sometimes, I still hear people saying that when they will have contract-based integration tests in place, they don’t need other types of integration tests anymore - including E2E tests. That’s simply not true. While contract testing is a great way to find out earlier about the impact of a change in a specific consumer or provider further downstream, in many cases, I wouldn’t rely on these tests alone before moving to production. Because of its asynchronous nature, contract-based integration testing only verifies whether a consumer and a provider speak the same language - can a consumer understand the message returned by a provider in a specific situation? It does not verify that the request or the response message reaches the other party in the first place, for example. In other words, it doesn’t test connectivity between a consumer and a provider. And because integration testing is broken down into individual consumer-provider pairs, you don’t see the entire system working ‘as a whole’. This means you might want to keep a few end-to-end tests in place, even when you’ve got good contract testing coverage across the board. The above is not a complete list of challenges with contract testing, but the ones I mentioned here are those that come up most often.
Have you seen this? If you haven't, you should. I think everyone needs to. Wealth inequality on a scale this extreme is almost impossible to explain. You have to experience it to understand. Go ahead. Try it out. Where is the top of this graph? Good question. Keep
Slop is without a doubt everywhere. Be it in restaurant’s menus, music playlists, or online game storefronts, it is now impossible to escape it. Yet, I’ve never met anyone who was actually looking forward to consuming that. No matter how hard it’s shoved down our throats, the human longing to connect with other people through art still remains. Raymond Kotewicz They will not let you filter A simple solution would be to have slop filters. Automatically label AI-generated trash, and let users hide it if they don’t want to see it. So far, I don’t think any of the major internet platforms has implemented this. The common excuse for why they don’t let you easily filter out slop is that it would be technically too difficult. Let me be clear with everyone here: this is complete bullshit. We’re talking about companies that can hire some of the most talented engineers in the world. I don’t think anyone seriously believes they can’t come up with a way to guess if a file has been generated by AI or not. 90% of the slop out there stands out so much everyone can see how it was made after looking at it for 5 seconds. A more plausible reason for the lack of slop filter is that they are simply testing out the waters. They are checking if users will tolerate it. The question tech executives want answered is: will people buy this garbage? And if the answer to that question is yes, here’s what they will do: they will start generating it themselves. They don’t need the useless meat proxies who think typing ten words and pressing enter makes them creative. They definitely don’t want to verse anyone royalties when they could just be making a one time purchase of tokens. If you think this is not real, just ask Tim Sweeney. I bet he will be more than happy to confirm. Roman Navarro Curation by humans for humans So now that it’s clear that tech companies will not save us from drowning in slop, it’s time to turn back to actual humans instead. The good news is they are a lot of people who are here to help you. There are thousands of people on the internet who will search through mountains of content to find the perfect piece of art they want to share with the world. We don’t explicitly call them curators. They are streamers, bloggers, journalists, DJs, overly enthusiast fans, or simply your friends. Some of those people are seriously amazing. There are DJs out there who will spend thousands of hours digging through crates to craft you the perfect ninety minutes of music. Why do you still need those machine-generated playlists? The alternative to blindly trusting the output of a recommendation algorithm isn’t always to become an expert in every field of art. Sometimes you just have to put the trust you had in a machine back into another person. Back to the real world? The real long term solution would be to stop relying only on the internet for distribution. This is already a thing in the music industry. Every city has a record shop that will sell you a carefully selected set of vinyls. For many musicians, physical sales (and concerts) are a much better source of income than streaming. The same goes for the movie. While text-to-video AI is a thing, the real money isn’t made by generating 30 second TikTok dramas. The real money comes from people paying tickets to see a full-length movie in a theater. Sadly I’m not too optimistic about my own field: video games. Somehow it seems the direction we’ve taken is the opposite. We’re all in on online distributions platforms. We have fully accepted them as our new digital overlords. Next month GTA V is coming out without a disk in the box. Sony already announced that the next Playstation will not support physical media. Physical distribution is not even mentioned in the pitch of the average indie publisher. In Breda, the small Dutch city where I live, we used to have two dedicated video games shop. Higher interests rates, expensive rents, and various policy failures have done their jobs: they are both closed. I don’t think this is a good sign for the survivability of the gaming industry.
Understanding how assigning anthropomorphic traits to agents can improve their effectiveness and interaction.