When HR Needs a Ticket System

TL;DR

• The core decision: whether the queue is visible to more than one person, because a queue exists either way.
• When doing nothing is right: when volume is low enough that one person holds it all and nothing has been lost.
• What has to be true: somebody other than the original recipient can see what's outstanding and pick it up.
• How the options split: by who can see the queue, which matters more than what the tool is called.
• Decision rule: if a request disappears when one person is away, the arrangement has already failed.
• Outcome to expect: fewer lost requests and a team that can take holiday.

The Request That Went Nowhere

Somebody asks HR a question. It's a reasonable question with a real deadline attached, and it goes to the HR lead's inbox on a Thursday afternoon.

The HR lead reads it, thinks it needs checking, and mentally files it for Monday. Then Friday is difficult, Monday brings something urgent, and the message moves down the inbox. Nobody else knows it exists. Three weeks later the person asks again, apologetically, and by then the deadline has passed.

Nothing here is negligence. It's the entirely predictable behaviour of a queue held in one person's memory, with no external representation, competing with everything else in the same inbox.

Recommended Tools

Best tools for HRIS Software

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

What makes this hard to fix is the objection that arrives immediately, and it's a real one. HR resists ticketing because it feels impersonal. The function deals with people at difficult moments, and a system that responds with a reference number reads as a wall. Nobody wants to be the department that made asking for help feel like a complaints procedure.

But the thing that actually felt impersonal in the story above was losing somebody's request for three weeks. The ticket system is not what makes HR distant. Being unreachable and unreliable is what makes HR distant, and a visible queue is one of the more effective ways to stop being either.

So the reframe worth holding: the question is not whether to introduce a queue, because you already have one. It's whether the queue lives somewhere only one person can see, and what happens to it when that person is away.

When You Genuinely Do Not Need to Act Yet

Your current setup is genuinely fine. Requests arrive at a rate one person absorbs comfortably, they get answered within a day, and nothing has been lost. At that volume a personal inbox is faster and warmer than anything you'd replace it with, and the effort of introducing structure would be spent on making a working arrangement more formal.

Friction is starting to show. A request was missed, somebody had to chase, or a query sat unanswered while its recipient was on leave. These are early signals and the first fixes are small: a shared mailbox, an agreed rule about who picks things up, a note of what's outstanding somewhere two people can see.

It has become a real cost. People chase routinely, the same question arrives repeatedly with no written answer, or nobody can say what's outstanding without asking each team member individually. At that point the queue has outgrown memory and the cost is being paid by whoever is waiting.

The edge case that forces it. Requests that carry a deadline with consequences, or that involve sensitive matters where a record of what was asked and how it was handled genuinely matters. What must be recorded, who may see it and how long it's kept differ by jurisdiction and by the nature of the request, so establish what applies where you operate with local advice before designing anything around it.

Five Questions This Reader Asks at 11pm

Does HR really need a ticketing system? Not necessarily a system, and almost certainly a visible queue. The distinction matters, because the benefit people want is that requests don't vanish and somebody else can pick them up, and that can be achieved with a shared mailbox and an agreed rule long before anybody buys software. Buying is warranted when the volume makes a shared mailbox unmanageable, not when the idea of structure first appeals.

At what size does this become necessary? Size is a weak predictor and everybody asks in those terms. The better signal is whether anything has been lost, and whether the team can cover for each other. A small team handling high-volume, high-consequence requests needs this sooner than a larger team fielding occasional queries. If somebody being away means their requests stop, you've reached the threshold regardless of headcount.

Won't this make HR feel bureaucratic? It can, and whether it does is almost entirely about implementation rather than tooling. The things that make it feel cold are specific and avoidable: replies that arrive without a name attached, no route to reach a person, an auto-response promising a timescale nobody meets, and a form that asks for information before letting somebody describe the problem.

What shouldn't go through a ticket? Anything genuinely sensitive or distressing, anything where the person needs to be heard rather than processed, and anything urgent enough that queuing it adds risk. Those should have a named route to a person, said out loud and repeated, because people default to whatever channel is presented as official.

Do we need to set response targets? A stated expectation helps far more than a formal target. People chase because they don't know whether something is being handled, and a simple statement about when to expect a reply removes most of that. Formal targets create their own problems: work gets prioritised by clock rather than by importance, and anything complicated gets a holding reply to stop it ageing.

What Breaks Before You Fix It

Most teams arrive at this question through accumulating symptoms rather than a decision. Each symptom points at a different smallest fix, and matching them saves you buying more than you need.

The first three rows are the common path and they're all fixable without buying anything. A shared mailbox, an agreed rule and a stated expectation solve a surprising proportion of what teams reach for a system to solve, and doing them first tells you whether the residual problem is volume or something else.

The last row is the one worth noticing because it's an argument people rarely make for themselves. A team with no record of what arrives cannot describe its own workload in a resourcing conversation. Saying HR is busy carries no weight. Showing what came in, what was completed and what is ageing carries a great deal, and it's a by-product of the same arrangement that stops requests being lost.

Five Diagnostic Questions You Can Self-Assess Against

What happens to requests when somebody takes a fortnight off? Answer honestly. If the answer is that they wait, or that somebody goes through the inbox afterwards, the arrangement depends on an individual's presence. That's the clearest single indicator, and it's independent of volume.

Can you say what is outstanding right now? Not approximately. Specifically, across the team, without asking anybody. If you can't, the queue exists only in several people's heads, and nothing can be prioritised across it because nobody can see it all.

How many requests are the same request? Sample a fortnight. The repeated ones are usually a small set, and each is a written answer waiting to be produced. This is the cheapest intervention available and it's routinely skipped in favour of process design.

When somebody asks about something difficult, where does it go? There should be a named route that isn't the general queue, and people should know about it. If sensitive matters arrive through the same channel as a payslip query, either the channel needs a private path or the sensitive matters need a different one.

Would you know if something had been sitting for a fortnight? Ageing is the failure mode that visible queues catch and inboxes don't. In an inbox, an old message simply moves down and out of view. Anything that shows what's oldest converts that invisible drift into something somebody notices.

Six Ways HR Teams Handle Incoming Requests, Reviewed

Individual inboxes

Everything goes to whoever the person knows. It earns its place on relationship and speed: the recipient usually has context, replies are personal, and for somebody with a delicate question, going to a specific person they trust is exactly right.

Where it falls short is everything structural. The queue is invisible, nothing can be covered when somebody is away, and requests compete with every other message in the same place. It also distributes service quality by who you know, which advantages people who've been there longer and disadvantages exactly the people most likely to need help.

Keep it for the relationships that matter. Add something visible alongside it rather than trying to stop people using it, because they won't.

There is a fairness argument here that HR teams rarely make out loud, and it is the strongest case for adding something visible. When the route to help is knowing who to ask, the people who get served fastest are the ones who have been there longest and are best connected, which is systematically not the people most likely to need help. A published route does not remove the personal relationships. It gives everybody else a starting point.

A shared mailbox everybody watches

One address the team monitors collectively. It earns its place as the highest-value change available for the least effort. Requests survive somebody's absence, two people can see what's outstanding, and it costs nothing but an agreement.

Where it falls short is claiming and ageing. Without a convention, two people answer the same thing or both assume the other has. And old messages sink out of view exactly as they do in a personal inbox, so the ageing problem isn't solved, just shared.

Agree a claiming convention on day one, however crude, and have somebody scan for old items on a fixed rhythm. That combination takes a shared mailbox a surprisingly long way.

The convention matters more than its elegance. Teams spend time designing folder structures and status labels when what actually prevents duplication is somebody replying in the thread to say they have it. Start with that, and add structure only when a specific failure demands it, because an elaborate scheme nobody follows is worse than a crude one everybody does.

A chat channel

Requests arrive in a shared channel where the team and sometimes everybody can see them. It earns its place on speed and informality, and it has a genuine side benefit: people see questions others have asked, which reduces repeats without anybody writing documentation.

Where it falls short is that chat has no concept of outstanding. A message scrolls away, and something not answered immediately is functionally lost. It's also public in a way that's wrong for a meaningful share of what HR handles, and people will self-censor, which means the sensitive things go somewhere else or nowhere.

Good as a supplement for quick questions. Poor as the primary route, because the medium cannot represent a queue.

There is a specific risk worth naming if HR is present in general channels. A question asked publicly about somebody's own circumstances is visible to colleagues, and people do not always think about that before typing. Where a question should not have been public, moving it to a private conversation quickly and without comment is worth doing as a matter of habit rather than treating each case as a judgement call.

A form that creates a tracked request

A structured entry point producing something with a state. It earns its place because it's the first option here where outstanding work has an existence independent of anybody's attention, and where ageing is visible rather than inferred.

Where it falls short is the form itself. A form asking for a category, a priority and a reference before letting somebody describe the problem is where the bureaucratic feeling comes from, and it's usually the result of designing for reporting rather than for the person. People also don't know which category their question is, and forcing the choice produces bad data and irritation together.

Keep it to a free text box and one optional category. You can classify afterwards; they can't.

One addition earns its place: a field for when they need it by. It is the single most useful piece of structure because it lets the team prioritise on something real rather than on arrival order, and unlike a category it is a question the person can definitely answer. Most people are also more reasonable about deadlines than teams expect, and knowing that something is genuinely not urgent is as useful as knowing that it is.

A full service desk with tiers and targets

A structured operation: routing, categories, response targets, escalation, sometimes a knowledge base attached. It earns its place at genuine scale, where request volume is high enough that triage is a real activity and where the reporting genuinely informs resourcing.

Where it falls short is weight. Tiers mean the first responder frequently can't resolve the request, which adds a handover the person experiences as being passed around. Targets shift prioritisation toward the clock, and anything complicated attracts a holding reply to stop it ageing, which looks like responsiveness and isn't. It also takes real effort to configure and maintain.

Worth it when the volume justifies triage. Below that, the structure costs more than it returns and the coldness is real.

If you do implement tiers, be deliberate about what the first tier can actually resolve. A first line that mostly forwards is a handover the person experiences as being passed around, and it adds delay while appearing to add capacity. Tiering works when the front line resolves the large majority of what it receives, and that requires giving those people real access and real permission rather than a script.

A rota where one person absorbs everything that week

One team member takes all incoming requests for a period while the others work uninterrupted. It earns its place as the least discussed and most effective option for small teams, because it addresses a problem the others don't: constant interruption preventing anybody from doing sustained work.

Where it falls short is that it needs a visible queue underneath it, or the handover at the end of each period loses whatever was in progress. It also concentrates unpleasantness, so it only works if the rotation is genuinely shared and the week is recognised as real work rather than an addition.

Combine it with a shared mailbox and a handover note. For a small team drowning in interruption, this frequently does more than any tool.

The handover note should record what is in progress and what the person on duty has promised, because a commitment made on Friday and forgotten on Monday is worse than no commitment. Keep it short. Anything longer than a few lines will not get written during a busy week, which is precisely the week it matters most.

The Decision Table

The second row is the threshold that actually matters, and it's independent of headcount. An arrangement where requests stop when one person is away has already failed; it just hasn't produced a visible casualty yet. That's the point to act, and the action is an agreement rather than a purchase.

The seventh row is where buying genuinely helps, and the qualifier matters. Triage being real work means somebody is spending meaningful time deciding who should handle things, not merely answering them. Below that threshold, the routing machinery adds handovers without removing effort.

Keeping It From Feeling Bureaucratic

This is the objection that stops most HR teams, and it's worth taking seriously rather than dismissing, because badly implemented it's completely correct.

The coldness comes from a small number of specific choices, and each has an alternative.

Replies without a name. A response from a system, signed by a function, reads as processing. The same response signed by a person reads as help. Nothing about a tracked queue requires anonymity, and teams adopt it by default because the tool defaults that way.

No route to a person. If the only way to reach HR is a form, the message is that you are a request. Publishing a named route, and meaning it, costs nothing and changes how the whole arrangement reads. People will not abuse it nearly as much as teams fear.

Promises nobody keeps. An automatic acknowledgement stating a timescale, followed by silence past that timescale, is worse than no acknowledgement. It teaches people the system lies. State something conservative you will actually meet.

Forms that interrogate before listening. Asking somebody to select a category, a priority and a location before describing their problem puts the organisation's reporting needs ahead of their situation. One box, and classify afterwards.

Everything through one door. Some matters need a private conversation, not a queue position. If there is no visible alternative, people will either use the general channel and feel exposed, or say nothing. Name the alternative explicitly and repeat it, because people follow whatever is presented as the official route.

One further thing helps more than any of the above, and it's about behaviour rather than design. When somebody sends a message directly to a person instead of through the channel, answer it. Then, having answered, mention where it lives for next time. Refusing to answer messages is how a team becomes the department that stopped helping, and it damages far more than the queue improves.

The same applies to the tone of what the system sends on the team's behalf. Automatic text gets written once, usually by whoever configured the tool, and then represents HR to every person who asks for help for years afterwards. It is worth someone reading those messages aloud before launch, because wording that looks neutral on a configuration screen frequently sounds curt when it arrives at the end of a difficult week.

Where HR Service Delivery Goes Wrong

The last row is the specific failure that formal targets produce. Once a response time is measured, the cheapest way to meet it is a reply that acknowledges without progressing, and teams under pressure discover this quickly. The numbers improve, the experience doesn't, and the reporting now actively conceals the problem it was meant to reveal.

The third row is worth fixing before launch rather than after. An automatic acknowledgement is easy to configure and easy to configure badly, and the version that states a timescale the team cannot consistently meet does more damage than sending nothing at all, because it converts uncertainty into a broken commitment.

What to Put in Writing

The fifth row belongs before the others in sequence even though it looks like the least structural. A meaningful share of the volume in most HR queues is a small set of repeated questions, and writing those answers once reduces the problem you're designing for. Designing a system around a volume you haven't tried to reduce means building for the wrong size.

It also changes which system you would choose. A team fielding a large volume of genuinely varied requests needs routing and triage. A team fielding a large volume of the same eight questions needs those eight answers written down, after which the residual volume may not justify any purchase at all. Those look identical on a request count and call for completely different responses.

Questions to Ask Before You Commit

On absence. What happens when somebody is away for a fortnight? A bad answer is that it waits.

On visibility. Can you list what is outstanding? A bad answer is roughly.

On expectation. Do people know when to expect a reply? A bad answer is that it depends.

On sensitivity. Where do difficult matters go? A bad answer is the same place.

On repeats. How many are the same question? A bad answer is that nobody checked.

On ageing. Would you notice something two weeks old? A bad answer is eventually.

On tone. Has anybody read the automatic replies aloud? A bad answer is that they are standard.

What Getting This Wrong Costs

The first cost lands on the person who asked and is invisible to everybody else. Somebody with a question about their pay, their leave or their circumstances waits, doesn't know whether they've been heard, and eventually asks again apologetically as though the delay were their fault. Each instance is small. The accumulated effect is an organisation where people learn that asking HR is unreliable, and they stop asking, which removes the signal you most need.

The second cost is on the team, and it's the reason this gets urgent rather than important. A queue held in individual memory cannot be shared, which means nobody can be properly away, nobody can pick up a colleague's work, and every absence produces a backlog somebody pays for afterwards. Teams in this position describe it as being busy. What they actually have is an arrangement that doesn't survive normal human events.

The third cost is the argument you can't make. Without any record of what arrives, a team asking for resource has only assertion, and assertion loses to a budget. The same visible queue that stops requests being lost produces the evidence for that conversation as a by-product, and teams consistently underrate this until they need it.

There is a fourth cost that falls entirely on the HR team and rarely gets named. Holding a queue in your own head is a constant low-level load: the nagging sense that something is outstanding, the checking of messages on a day off, the reluctance to take leave because of what will accumulate. A visible queue removes that even when the volume is unchanged, because the responsibility for remembering moves from a person to a list.

So before buying anything, work through the cheap fixes in order. Write answers to the questions that repeat. Put requests somewhere two people can see. Agree who picks up and when. State an expectation you will actually meet. If the problem persists after all four, it's genuinely a volume problem, and then a system is the right answer rather than a first resort.

When You Are Ready to Go Further

None of this needs software to begin. It needs a shared place requests land, an agreement about who picks them up, a stated expectation about when somebody will reply, and a named route for anything that shouldn't sit in a queue at all.

Add one habit alongside those: somebody scanning for the oldest items on a fixed rhythm. Ageing is the failure that visible queues catch and inboxes hide, and a few minutes on a regular schedule prevents the three-week disappearance that started this piece.

Pick a fixed moment for it rather than relying on somebody noticing they have a gap, because the weeks when nobody has a spare few minutes are exactly the weeks when things age. A standing slot at the same point each week survives a busy period in a way that good intentions do not.

The step after that, if volume genuinely warrants a system, is to categorise what arrives before you configure anything. Categories invented in advance rarely match what people actually ask, and a fortnight of rough tagging will tell you which routes matter and which exist only in somebody's mental model of how HR ought to be organised.

HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.

Frequently Asked Questions

The queue already exists. The only question is whether anybody else can see it.

Make it visible before you make it sophisticated.