HR Helpdesk and Ticketing: An Employee Service Guide

Every HR team in India already runs a helpdesk, whether or not anyone calls it that. The moment an employee asks "why has my PF not been credited?" or "I need an address proof letter by Friday", a service request has been raised. In most companies of 100 to 2000 people that request lands in a WhatsApp message, a reply-all email or a corridor conversation. An HR helpdesk — or more precisely an HR ticketing system — is simply the decision to stop treating those requests as informal favours and start treating them as work with an owner, a due date and a record.

This guide covers how to build one: the service catalogue, SLA design, tiering, knowledge base, routing, confidentiality, sensible automation and the metrics that tell you which policies are broken. It is sized for a lean Indian SMB HR team, not a thousand-seat shared services centre.

The symptoms of an unmanaged HR query load

Most HR leaders recognise their own week in this list.

There is no record. An executive answers a gratuity question from memory over WhatsApp; six months later the employee disputes it, the executive has left, and nobody can reconstruct what was said.

The same question gets answered fifty times. Investment proof season arrives and a dozen questions about 80C evidence, rent receipts and landlord PAN are answered individually, slightly differently, by three different people.

Response times depend on who you know. The employee sitting near HR gets an answer in ten minutes; the one in the Pune warehouse who emailed hr@ waits five days. This is invisible to HR, which only sees the queries it answered, and painfully visible to employees.

Escalation to the founder becomes the routing rule. Employees learn that the fastest path to a resolution is a message to the founder, so leadership ends up chasing a reimbursement of Rs 2,400.

Payroll queries get lost in email. A salary discrepancy raised on the 3rd sits in an inbox until the 12th, past the correction window, and becomes an arrears adjustment plus an apology.

What an HR helpdesk actually is

An HR helpdesk is a single intake point plus a structured workflow for employee service requests. Three things make it a helpdesk rather than an inbox: every request becomes a ticket with an identity, every ticket has an owner and a due time, and every ticket ends in a recorded resolution.

Around that core sit four supports — a service catalogue defining what employees can ask for, a knowledge base that answers common questions before a ticket exists, routing rules, and metrics.

It is not a complaint box. A helpdesk handles transactional requests, informational queries, corrections and genuine grievances. Positioning it as a complaint channel suppresses exactly the routine volume you want captured.

How an HR ticketing system differs from an ITSM tool bolted onto HR

Reusing an IT service desk for HR works for a while and then hurts.

Identity and context. An HR ticketing system should already know the employee's designation, department, manager, location, joining date and pay group. An IT tool knows an email address. That context is what routes a payslip query to the right payroll owner.

Confidentiality architecture. HR tickets include salary details, medical claims, POSH matters and disciplinary records. HR needs record-level restrictions where even other HR members cannot see certain cases; most IT tools treat all agents as broadly equivalent.

Native actions. An HR ticket often needs to do something — regularise attendance, revise a tax declaration, generate a letter with the correct signatory. When the helpdesk sits inside the HRMS, the action and the record are one transaction. When it sits outside, agents copy data between systems and the audit trail splits in half.

Employee expectations. An HR helpdesk must serve a shop-floor employee on a shared phone, in a language they read comfortably, without assuming familiarity with words like "SLA" or "escalation".

When to move off email

A shared inbox with disciplined labels, a tracker and a published response commitment is a legitimate version one. The failure is not email; it is having no categories, no owner field and no due date. Move to a proper system when volumes exceed roughly 150 to 200 tickets a month, when more than two people handle queries, or when you need confidentiality separation — thresholds to sanity-check against your own load.

Building the service catalogue

The employee service catalogue is the backbone: the list of things employees can ask HR for, in the employee's language, with an owner and a target turnaround for each.

Two rules keep it useful. Write category names the way employees speak ("Salary credited is less than expected"), not the way HR files them. And keep the top level short — eight to twelve parent categories — with the detail in sub-categories.

A worked catalogue for a typical Indian employer

The targets below are suggested starting points to calibrate against your own volumes and staffing, not benchmarks from research. Set them, measure attainment for two months, then adjust.

A 150-person company runs the same categories with fewer sub-categories and one owner. A 1,500-person company adds location as a dimension and splits payroll by pay group. Split a category only when its volume is large enough to change how you act on the data.

Fields to capture at intake

Keep the employee-facing form to four fields: category, a plain-language description, an optional attachment, and the date by which it is needed. Employee ID, department, manager and pay group should be pulled automatically.

Add one optional field that pays for itself: "Is this time-bound? If yes, why?" A visa appointment or a loan sanction deadline changes prioritisation legitimately, and asking is cheaper than guessing.

HR SLA design that survives contact with reality

An HR SLA is a promise about time. It fails either by being so ambitious that HR misses it constantly, or so loose that it gives employees no useful expectation.

Separate response from resolution

Response time is how long before a human acknowledges, confirms understanding and states what happens next. Resolution time is how long before the thing is done.

Employees tolerate slow resolution far better than silence. A four-hour response with an honest "this will take five days because the insurer must confirm" beats a silent two-day turnaround.

Define the clock before the hours

"Eight hours" means nothing until you define business hours — say 10:00 to 18:30, Monday to Friday, excluding the published holiday list — and pause the clock outside them.

For multi-shift or multi-location operations, decide whether the clock follows the employee's location or a central desk, and publish it. Decide explicitly whether the clock pauses while you await information from the employee; it usually should, visibly, on the ticket.

A workable priority matrix

Priority should be derived, not claimed by whoever is loudest. Combine impact with urgency.

Handling the payroll cut-off crunch

Payroll query volume spikes exactly when payroll capacity is lowest. Handle it with structure rather than heroics.

1. Publish the payroll calendar to all employees: input cut-off, processing window, credit date and query window. Ambiguity generates tickets by itself.
2. Freeze non-urgent payroll requests during processing, routing them to a queue whose SLA clock starts after the credit date — and say so in the auto-acknowledgement.
3. Keep a P1 lane open for genuine emergencies: salary not credited, wrong account, statutory deadline.
4. Pre-publish articles for the questions that always spike — why net pay changed, how a new joiner's first partial salary was computed, why tax moved after a proof update.
5. Staff a fixed daily payroll query window in the three days after credit, so specialists clear the queue in one block instead of being interrupted continuously.
6. Debrief after each cycle: which queries spiked, which were caused by a real error, which by an unclear payslip label.

Seasonal spikes

Indian HR calendars surge predictably. Plan capacity the way retail plans for festival season.

Where a resolution depends on a third party — an insurer, a PF office, a bank — do not put it under your own resolution SLA. Commit instead to a handoff SLA: "we will submit your claim within one business day and update you every three days until it closes." That is a promise you can keep.

The tiering model for HR case management

Tiering matches the difficulty of a query to the cost of the person answering it. Without it, your most expensive specialists spend their time on questions a well-written article could answer.

Tier 0 self-service is where the leverage is

If an employee can see their own leave balance, download a payslip and read the reimbursement limit without asking anyone, that is a ticket that never existed.

Three things make tier 0 self-service work: the data must be current and correct, because one wrong leave balance destroys trust in the portal permanently; the answer must be findable in two or three taps; and it must work on a phone, because for much of the Indian workforce the phone is the only device.

Tier 1 needs a mandate, tier 2 needs protected time

Tier 1 owns the queue — resolve what they can, gather complete information for what they cannot, route accurately. Give them a documented list of what they may decide alone; without it, tier 1 becomes a forwarding service that adds delay and no value.

Tier 2 people have other jobs. Protect them with batching, a defined daily window for helpdesk work, and route to a function rather than a named person so leave does not stall the queue.

Tier 3 should be rare by design. If leadership sees more than a handful of tickets a month, something below is broken: unclear policy, an under-empowered tier 1, or a culture problem worth investigating separately.

Routing rules

Write routing as explicit rules, not tribal knowledge.

1. All tickets enter the tier 1 queue by default, except sensitive categories, which go straight to the restricted queue.
2. Auto-assign by category where the mapping is unambiguous — all Form 16 and TDS tickets to payroll.
3. Auto-assign by employee attribute where relevant: location for attendance, business unit for HRBP matters, pay group for payroll.
4. Tier 1 may escalate only after capturing a defined minimum set of information for that category. This single rule eliminates most escalation ping-pong.
5. Escalation transfers ownership but never removes visibility; the original owner stays on the ticket and remains accountable for the employee-facing update.
6. Time-based escalation runs automatically at 50 per cent, 80 per cent and 100 per cent of the resolution SLA.
7. Reopened tickets return to whoever closed them, with a mandatory reopen reason.
8. Nothing closes without a plain-language, employee-facing resolution note.

Publish the escalation path to employees. Employees escalating to the founder is a reasonable response to having no published alternative.

A knowledge base for HR that actually deflects tickets

Ticket deflection is the cheapest capacity you will ever add, but only if articles are findable, readable and trusted. Most internal HR wikis fail all three.

Search terms must match employee language: an article titled "Reimbursement Policy v3.2" will never be found by someone searching "how to claim mobile bill". The answer must appear in the first three lines. Actions should be linked, not described. And every article needs a date and an owner, because an undated article is assumed stale.

Article template

``` Title: [The question, in the employee's words]

Short answer [Two to three sentences. The actual answer, immediately.]

Who this applies to [Employment type, location, grade or tenure conditions, if any.]

Steps 1. [Action with a direct link] 2. [What the employee should see when it worked]

Timelines [When it takes effect, when it reflects, when money moves.]

Common problems - [Problem]: [Fix]

Still need help? Raise a ticket under [Category] > [Sub-category]. Response within [SLA].

Owner: [Role, not a person] | Last reviewed: [Date] | Next review: [Date] ```

Worked example

``` Title: My salary is lower than last month. Why?

Short answer Net salary usually changes because of a tax recalculation, a loss-of-pay day, a mid-month revision, or a one-time recovery. Your payslip shows each as a separate line. Compare this month's payslip with last month's before raising a ticket.

Steps 1. Download the current and previous payslips from the employee portal. 2. Compare Earnings first: a change here usually means LOP days, a revision effective mid-month, or a variable component that did not apply. 3. Compare Deductions: income tax often changes after proofs are verified. 4. Check the Days Paid field against your leave record.

Timelines Tax is recalculated monthly against projected annual income, so a change in one month is normal and not an error by itself.

Common problems - Proof rejected: tax rises the following month; the reason is shown in the declaration section of the portal. - New joiner: first salary is computed from your joining date. - Recovery line: usually notice period, asset or advance recovery.

Still need help? Raise a ticket under Payslip and Salary > Salary lower than expected. Attach both payslips. Response within 4 business hours.

Owner: Payroll Lead | Last reviewed: [date] | Next review: [date + 6 months] ```

Build it from ticket data, not ambition

Do not start by writing a hundred articles. Export the last three months of queries, count them by topic, and write articles for the top ten.

Then adopt a standing rule: any question asked three times in a month gets an article before it is asked a fourth. Add a one-click "Was this helpful?" — a run of "no" responses is your best warning that a policy changed and the article did not.

True deflection is hard to measure precisely. A workable proxy is to track article views against ticket volume in the same category over the same period. Treat any deflection figure as directional; the point is to find which articles do nothing, not to produce a number for a slide.

Intake channels and why the single queue matters

Multiple channels are fine. Multiple queues are not. When WhatsApp requests live in one person's phone and email requests live in an inbox, you cannot see total load, cannot balance work, and requests fall between the two.

Employees who will never use a portal

Some employees will not use a portal — not from stubbornness, but because of shift patterns, shared devices, literacy or habit. In many Indian companies they are a large share of the workforce.

Log it for them. When someone walks up or calls, HR creates the ticket during the conversation and gives them the number and expected date. The employee experiences a conversation; the system gets a record.

Add an assisted layer — a supervisor or site coordinator who raises tickets for their team, with the outcome still going directly to the employee so nothing is filtered. A kiosk tablet or a fixed HR desk hour per shift reaches people who will never log in from home. And meet people in the language and channel they already use: WhatsApp intake with short regional-language menus gets far higher usage than a portal and still creates a proper ticket.

The rule to hold firm on is simple. The channel can be anything; the queue is always one.

Every ticket should trigger an immediate acknowledgement carrying the ticket ID, the category as understood, the committed response time, a link to the ticket and a link to the most relevant article. That last element is quiet deflection.

Confidentiality and sensitive cases

Grievances, harassment and POSH matters, mental health disclosures, medical information, disciplinary proceedings and whistleblower reports cannot sit in a general queue. Design this before launch, not after the first uncomfortable case. The guidance here is organisational; for anything with legal weight, take advice from qualified counsel and follow your committee's own procedure.

A general queue is built for visibility and load balancing. Any tier 1 agent can see it, tickets are reassigned freely, and notifications go to team channels. Every one of those properties is wrong for a harassment complaint. An employee who suspects their complaint will be visible to colleagues simply will not raise it — you get fewer reports, not fewer problems.

Separate intake, storage and access

• A distinct intake option that never enters the general queue and is not visible in general queue counts.
• A named, small set of authorised handlers, typically the HR head, the committee's presiding officer and legal as relevant.
• Record-level access control, so other HR members cannot open, search or export the case.
• No manager notifications, no team channel alerts, no default CCs.
• Attachments stored with the same restrictions as the ticket, never in a shared drive folder.
• An access log showing who opened the record and when.

Offer a way to report without naming oneself, and be honest about the limits: some matters cannot be fully investigated without the complainant's participation. Semi-anonymous reporting, where identity is known only to one designated officer, is often the practical middle ground.

Record-keeping and data protection

Keep sensitive records factual and minimal: what was reported, what steps were taken, what was decided and when. Avoid speculation and personal characterisations. Retain for the period your policy defines, restrict access throughout, and dispose of records in a controlled way.

Four operating principles hold regardless of the specific data protection regime. Collect only what the request needs — a letter request does not need a medical report. Restrict access by role. Never move employee data into unofficial channels such as personal WhatsApp or unmanaged spreadsheets, which is the most common real-world leak. And define retention for ticket data and attachments, then actually apply it.

Train handlers on first response: acknowledge without judgement, avoid promising outcomes, explain the process and its confidentiality limits, and document contemporaneously. Train tier 1 agents on what to do when a sensitive matter lands in the general queue by mistake — move it immediately, do not discuss or forward it, and note only that a transfer occurred.

Automation and AI assistance, done responsibly

Automation should remove typing, not judgement. Applied well it returns hours; applied badly it produces confidently wrong answers about someone's salary.

What automates safely

Auto-categorisation is low-risk because a human sees the ticket anyway and can recategorise; track the correction rate to know how far to trust it. Auto-acknowledgement with a suggested article deflects some volume at no cost. Rule-based routing is deterministic and auditable, and automatic status updates remove a whole class of "any update?" follow-ups.

Draft replies with a human in the loop are the real time-saver: generate a suggested answer from your own knowledge base, which the agent reviews and edits before sending. Thread summarisation helps handover and escalation, and spike detection tells you when forty people raise the same category in two hours because something broke upstream.

What should never be automated

Never auto-send an answer stating a financial figure — salary, tax liability, gratuity, F&F amount. Computation context is easy to get subtly wrong and the consequences are real.

Never auto-close on the assumption that silence means satisfaction. Auto-closing after a stated waiting period with clear notice is fine; treating no reply as resolution is not.

Never let an automated system handle a grievance, POSH matter, mental health disclosure or disciplinary case. Never automate policy exceptions that carry cost or precedent, and never route sensitive case content through external tools not covered by your data protection arrangements.

Guardrails worth writing down

Ground every drafted answer in your own published policies, not general knowledge — an answer describing some other company's leave policy is worse than none. Show the agent the source article alongside the draft, and keep the human edit visible in the audit trail.

Measure quality: reopen rates and satisfaction on AI-assisted tickets should be no worse than on manually written ones. If they are worse, narrow the scope. Tell employees when an assistant is involved, and always offer a path to a human.

Metrics that matter

Measure to find broken processes, not to police the HR team. The moment a dashboard is used mainly to rank agents, people close tickets prematurely and log less.

Read them together

No metric means anything alone. High closure speed plus a high reopen rate means tickets are being closed to hit SLA, not solved — fix the incentive, not the agent.

High volume plus high first contact resolution means the queries are easy and repetitive: a knowledge base opportunity, not a staffing one. High volume plus low first contact resolution means the category genuinely needs specialists, or tier 1 lacks authority; check the mandate before adding headcount.

Good SLA attainment plus poor satisfaction means you are fast and unhelpful. Falling volume plus falling satisfaction is the dangerous one — employees may have stopped using the system rather than stopped having problems.

Run a 45-minute monthly review with a fixed agenda: top five categories by volume, SLA attainment, the five oldest open tickets, reopen reasons, satisfaction comments read aloud, and two upstream fixes committed with owners and dates. A review that ends without an upstream fix was a status update.

Using ticket data to fix upstream problems

Every ticket is evidence that something upstream is unclear, broken or badly communicated. This is the highest-value output of an HR ticketing system and the one most companies never use.

Policy ambiguity. If forty people asked the same policy question this quarter, the policy is not clear or nobody can find it. Rewrite the clause in plain language, publish an article, link it from the policy, then track the category for two months. If volume does not drop, the problem is findability, not wording.

Payroll errors. Cluster payroll tickets by root cause, not symptom. Fifteen "salary lower than expected" tickets might be one master data error affecting fifteen people, or fifteen correct tax recalculations. The first needs a payroll fix, the second a payslip that explains itself.

Manager gaps. Normalise volume by team size. If one department raises three times the tickets per head on leave approvals and regularisation, the likely cause is a manager who does not approve on time or does not know the policy. That is coaching, not helpdesk capacity.

Communication failures. A spike straight after an announcement means the announcement did not answer the obvious questions. Build the habit of writing the five questions employees will ask and answering them in the same message.

A quarterly root-cause exercise

1. Export the quarter's tickets with category, sub-category, resolution notes and time to resolve.
2. Take the top five categories by volume and read twenty resolution notes from each.
3. Classify each as a knowledge gap, a policy gap, a system gap, an accountability gap, or a genuine one-off.
4. Total the counts by gap type. This is your improvement backlog, ranked by real cost.
5. Pick the top three, assign owners and dates, and put them on the next monthly review agenda.
6. Measure the affected categories next quarter and report whether volume actually moved.

A 60-day implementation plan

Sixty days is realistic for 100 to 2000 employees if the scope stays honest, assuming an HR ops owner spending about a quarter of their time on it with support from payroll and IT.

Days 1-10, understand the demand. Export or reconstruct three months of queries from email and chat; proportions matter more than precision. Tally them into rough categories, count the top twenty questions, and time-sample a week so you see effort rather than volume alone. Agree which categories go live first.

Days 11-20, design the catalogue and SLAs. Draft categories, sub-categories and owners. Set deliberately conservative targets — it is easier to tighten a promise than to loosen one. Define business hours, holiday handling and clock-pause rules, build the priority matrix with real P1 examples, define the restricted queue and its handlers, and write routing and escalation rules as an explicit list. Get sign-off from the HR head, the payroll lead and one sceptical manager.

Days 21-35, build content and configure. Write articles for the top ten questions and have two non-HR employees mark anything they did not understand. Configure categories, forms, routing, SLA timers, escalation notifications and restricted queue permissions. Set up auto-acknowledgement, build the metrics dashboard now so measurement starts on day one, and configure a closure survey of one rating and one comment.

Days 36-45, pilot. Run with one department or location of roughly 100 to 200 employees, including some non-desk staff, routing all their queries through the system — including verbal ones HR logs on their behalf. Hold a 20-minute standup twice a week. Delete categories nobody uses, add ones people kept trying to describe, and recalibrate SLAs against actual attainment.

Days 46-60, launch and stabilise. Send the launch communication and run short walkthroughs per location or shift. Go live for everyone, keeping old channels open but routed into the same queue. Over-staff the queue for the first fortnight, because early experience determines adoption. At day 60, run the first monthly review and commit the first two upstream fixes.

Deliberately leave out full automation, chatbots, multi-language knowledge bases and integration with every adjacent system. Adoption is the only thing that matters in phase one.

Launch communication

Adoption is a communication problem more than a technology one. Employees adopt a channel when it is faster than the alternative and feels safe.

Explain the change in terms of employee benefit: your request now has a number, an owner and a promised date, and you can see its status. Publish the response and resolution commitments in a table employees can screenshot.

Say specifically what happens to sensitive matters and who can see them. That single paragraph does more for grievance reporting than any amount of policy text.

Show rather than describe. A 90-second screen recording and a printed one-pager for noticeboards outperform a long email. Say what happens to the old channels — if WhatsApp still works, explain that it now creates a ticket; if a personal HR email is retiring, give a date.

Brief managers separately a week before launch, covering what they can resolve themselves, what to route, and how to raise tickets for their team. Managers who feel bypassed quietly discourage use; managers who see work removed from their plate promote it.

Common mistakes

Building the catalogue from HR's filing system. Jargon categories get misused by employees, which corrupts your data and your routing. Test names with real employees before launch.

Setting SLAs before you know your volume. Aspirational targets set in week one are missed by week three, and a routinely missed target stops being a target.

Treating the helpdesk as a performance monitoring tool. People respond by closing tickets prematurely, avoiding hard cases and logging less. Review the system publicly; coach individuals privately.

Letting sensitive matters sit in the general queue. The highest-cost mistake here, and the one you cannot fix retrospectively.

Keeping side channels alive without integrating them. If the HR manager's personal WhatsApp resolves things faster, that is where the volume goes. Every channel must create a ticket, walk-ins included.

Closing tickets without a resolution note. "Done" is not a resolution. Without a note there is no record, no reusable answer and no evidence six months later.

Skipping the knowledge base because HR is too busy. The busyness is caused by the missing articles. One hour on your highest-volume category returns more time than any process tweak.

Ignoring backlog ageing. Teams naturally work the newest tickets, so old ones rot quietly until they become escalations. Review the oldest bucket weekly.

Over-automating too early. Auto-replies deployed before the content is good produce confidently wrong answers at scale.

Measuring without acting. A dashboard that never changes a policy is decoration.

Forgetting ex-employees. Form 16 requests, experience letters and F&F disputes come from people without portal access. Give them a route or they will email the founder.

Implementation checklist

Foundations. Catalogue in employee language; an owner per category by role; targets documented as starting points; business hours and clock-pause rules defined; priority matrix with written P1 examples; escalation thresholds configured.

Tiering and routing. Tier 1 resolution mandate documented; tier 2 specialists named by function with a batching window; tier 3 criteria narrow; routing rules written out; minimum information required before escalation; reopen handling agreed.

Knowledge base. Top ten articles written; each owned by a role with a review date; readability tested by non-HR employees; titles matching employee vocabulary; feedback enabled; the "asked three times" rule adopted.

Channels. Single queue across all routes; email auto-conversion configured; portal tested on a low-end device; chat intake through an official number; walk-in logging rehearsed; manager-on-behalf creation enabled; ex-employee route defined.

Confidentiality. Sensitive categories separated at intake; restricted queue with named handlers; access controls tested by attempting access as a normal agent; no manager or channel notifications; attachments restricted; access logging with a named reviewer; handler training done; retention defined.

Automation. Auto-categorisation with correction tracking; acknowledgement carrying ticket ID, SLA and article; drafts grounded only in internal content; mandatory human review before any financial figure; sensitive categories excluded; employees told when an assistant is involved.

Metrics and launch. Dashboard live before go-live; metric definitions documented; closure survey configured; weekly review for the first quarter; monthly review with a fixed agenda; quarterly root-cause exercise scheduled; manager briefing a week ahead; commitments published; walkthrough video and one-pager ready; queue over-staffed for two weeks.

Frequently asked questions

How many people do we need to run an HR helpdesk?

Fewer than most teams expect, if tier 0 and the knowledge base work. Size it by measuring: track volume and average handling time per category for a month, multiply out, and add roughly 30 per cent for spikes and follow-ups.

A common shape in Indian SMBs is one HR ops generalist owning the queue with part-time specialist support from payroll and HRBPs. Treat that as a hypothesis to test, not a rule.

Should we buy a separate HR ticketing system or use our HRMS?

If your HRMS has a helpdesk module, start there. The ticket sits next to the employee's actual record, so the leave query, the payslip and the attendance correction are one click apart, and the action and audit trail live in the same place.

Buy a separate tool only if you need something the integrated option genuinely cannot do. A separate tool means duplicate master data, two audit trails and one more login for employees.

What HR SLA should we commit to?

Whatever you can actually keep, which you only know after measuring. Start conservative — say four business hours for response on transactional categories and two to three business days for resolution — then tighten once you have two months of attainment data.

Those figures are starting points, not benchmarks. A four-person team supporting 1,500 employees across three shifts will land somewhere different from a two-person team supporting 200 people in one office.

How do we handle HR queries that come over WhatsApp?

Capture the channel rather than fighting it. Route WhatsApp through a single official company number that creates tickets automatically, not through individual HR members' personal phones.

Two firm rules: personal numbers stop being a service channel from a stated date, and grievances or POSH matters never go through chat. The intake screen should say so and offer the confidential route instead.

What is a realistic ticket deflection rate?

There is no credible universal figure, and any number quoted as one deserves scepticism. What is reliable is the direction: good articles for your highest-volume categories reduce tickets in those categories.

Measure your own baseline before launching the knowledge base, then compare category volumes over the following quarter. Your baseline is the only benchmark that matters.

How do we keep grievances confidential in a small HR team?

Restrict handling to a named minimum, often the HR head plus the committee's presiding officer, and configure record-level access so other HR members cannot see or search the case.

Where the complaint involves someone in HR, define an alternate route in advance — a director, an external committee member, or external counsel — and publish it before you need it.

Won't a ticketing system make HR feel impersonal?

Only if it replaces conversation rather than organising it. The ticket is the record; the conversation still happens over a call, a meeting or a walk-in, and HR logs it.

In practice the opposite tends to happen. When routine load is handled predictably, HR has more time for the conversations that need a human, and fewer employees feel ignored because their request has a visible status.

What do we do about ex-employees raising queries?

Ex-employees commonly need Form 16, experience and relieving letters, PF guidance and F&F clarifications, and they no longer have portal access.

A dedicated alumni email address that converts to tickets in the same system, with its own category and a clear SLA, solves it. Without one, these requests land on the founder.

Bringing it together

An HR helpdesk is not software. It is a decision to treat employee questions as work deserving the same discipline as any other service the company provides — a defined catalogue, an honest promise about time, a protected path for difficult cases, and the habit of using the resulting data to fix what caused the questions.

The sequence that works is unglamorous. Understand your demand before designing anything. Write the catalogue in employee language. Set conservative SLAs and earn the right to tighten them. Protect sensitive matters from day one. Write the ten articles that answer half your volume. Consolidate every channel into one queue. Then use the measurement to fix upstream problems rather than to grade your team.

Done properly, the payoff shows up in three places: employees stop feeling ignored, HR gets its week back, and leadership stops being the escalation path of first resort.

If you are ready to move HR queries out of inboxes and chat threads into a proper employee self-service portal with a helpdesk built on your actual employee data, CozyHR brings HRMS, payroll and helpdesk together in one place. Start a free trial or book a walkthrough, and see what your first month of ticket data reveals about your own organisation.