Setting up a helpdesk team

Update timeline

1. monitoring Oct 14, 2026, 12:00 AM UTC

   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.