back to Jitbit Blog home About this blog

Setting up a helpdesk team

by Alex Yumashev · Oct 14 2026

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:

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:

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:

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:

  1. Everyone handles everything, but you track which tickets take minutes and which take days.
  2. 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.
  3. 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.
  4. 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.

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.