How to Set Up an Internal IT Help Desk (Small Business Guide)

In short: set up an internal IT help desk by choosing one intake channel and publicising it relentlessly, defining a handful of request categories, setting priority levels that mean something specific, agreeing response targets you can actually hit, giving every request one owner, and writing up the five answers you repeat most. The tooling is the easy part; getting colleagues to stop tapping you on the shoulder is the real work.

Internal IT at a small company usually starts the same way. One person is vaguely "the technical one," requests arrive by Slack DM, corridor conversation, and the occasional email, and everything is held together by that person's memory. It works until they take a holiday.

Why internal IT is different from customer support

The mechanics look similar, but three things genuinely differ, and they change how you should set the system up.

Your users can find you. Customers have to email. Colleagues can walk over, DM you, or grab you in the kitchen. Any internal help desk competes with an easier informal channel, which means adoption, not features, is the hard problem.

Requests are often planned, not broken. A new starter needing a laptop and accounts isn't an incident, it's a predictable piece of work that happens every time someone joins. Customer support rarely has this category, and it deserves its own treatment. That distinction, incident versus service request, is the useful bit of ITIL to borrow, covered properly in help desk vs service desk.

The relationship continues regardless. An unhappy customer leaves. An unhappy colleague sits near you and asks again tomorrow. That makes visible fairness, being able to show why something is queued behind something else, more important than it is externally.

What you need before you start

• A single email address for IT requests, something obvious like it@ or helpdesk@
• A rough list of what you actually get asked for, from memory or from the last month of messages
• Agreement from whoever leads the company that requests should go through the channel, which matters more than any tool decision
• An honest sense of your capacity, because response targets you can't hit are worse than none

1Pick one intake channel and publicise it

One. Not "email or Slack or just ask me." Every additional channel multiplies the chance a request lands somewhere untracked and dies there.

Email is usually the right choice: everyone has it, it needs no training, and it works from a phone. Route it into a tool where each message becomes a ticket with an owner. Add a simple request form later if you find people leave out information you always need.

Then say so repeatedly. Announce it, pin it, and put it in the onboarding doc. Expect to redirect people for at least a month.

2Decide your categories

Keep this small. Five to eight categories covers almost every small company, and a long list slows down the person logging the ticket, which discourages logging tickets.

A typical starting set:

• Access, accounts, passwords, permissions
• Hardware, laptops, monitors, phones, peripherals
• Software, installs, licences, application faults
• Network, wifi, VPN, connectivity
• New starter and leaver, onboarding and offboarding
• How do I, questions rather than faults

The last two earn their place. Starter and leaver work is your most repeatable process and the one with the worst consequences when missed, an ex-employee with live access is a security problem, not an admin one. And separating questions from faults tells you where documentation would save you the most time.

3Set priorities that mean something

Priority levels are useless if they describe feelings. Define them by impact, and write the definitions down where people can see them.

Two rules keep this honest. Impact means impact on the business, not on the requester's mood. And if everything is urgent, nothing is, so if more than roughly one in ten tickets is arriving as urgent, your definitions aren't being applied.

4Agree response targets you can hit

Publish a first-response target rather than a resolution target. You control how fast you acknowledge something; you often don't control how fast a vendor ships a replacement part.

Something like: urgent within one hour, high within four working hours, normal within one working day. Modest targets you consistently meet build far more trust than ambitious ones you miss, and they give you a defensible answer when someone asks why their monitor request is behind an outage.

5Give every request one owner

Even if the IT team is one person, assign tickets explicitly. It sounds like pointless ceremony at that size, and it isn't: the moment you get a second person, cover a holiday, or bring in a contractor, unowned tickets start slipping. Building the habit while it's trivial is much easier than retrofitting it during a busy week.

Reassignment should be explicit too. Most dropped requests aren't dropped when they arrive, they're dropped at a handoff nobody recorded.

6Write up your five most repeated answers

Not a documentation project. Five short articles covering the things you explain constantly: how to connect to the VPN, how to reset your password, how to request software, what to do on your first day, how to get a new laptop.

Link them in replies rather than retyping. The measure of success is how often you send a link instead of an explanation, and this is usually the single highest-return hour an internal IT function spends.

Getting people to actually use it

This is the part that determines whether the system survives.

Be pleasant but consistent about redirecting. "Can you drop that in an email to it@ so it doesn't get lost?" works. Answering the DM anyway teaches people the DM works.

Answer tickets faster than DMs, visibly. Adoption follows self-interest more reliably than policy.

Never punish anyone for using the wrong channel. Redirect, then help. Making people feel bureaucratically told off is how you get a shadow process.

Show the queue. People are dramatically more patient when they can see they're third in line rather than suspecting they've been forgotten.

Get leadership to model it. If the founder emails IT rather than DMing, everyone else follows within weeks.

What to measure

Three numbers are plenty at this size: median first-response time, how many requests are open right now, and which category generates the most volume.

The third is the interesting one. It tells you where to spend an hour on documentation or a permanent fix rather than answering the same question forty times. If access requests dominate, your provisioning process needs work. If "how do I" dominates, you have a documentation gap, not a support problem.

When you need something bigger

Move to full ITSM when you genuinely need asset and licence inventory as part of daily work, when change control becomes a compliance requirement, or when you're formally reporting against ITIL processes. At that point Freshservice or Jira Service Management start earning their configuration cost.

Until then, the requirements are modest: email-to-ticket, categories, priorities, one owner per request, a small knowledge base, and response-time visibility. PileDesk ships IT support and IT service desk templates with those defaults already in place, and because pricing is flat per workspace you can run IT and HR side by side without paying twice, which matters given how much starter and leaver work spans both.