Answering a Question Is Not the Same as Doing Something

TL;DR

• An HR chatbot answers questions from documents. A ticket system creates a record that somebody has to close. These are different products solving different halves of the same complaint.
• Roughly four in five inbound HR messages at a company under 500 people are questions whose answers already exist in writing. The rest need somebody to do something, and those are the expensive ones.
• Buying an answering tool when your real problem is untracked requests gets you a well-informed queue that is still untracked. Buying a case system when your real problem is repetition gets you ten thousand tickets that all say the same thing.
• The test is not what the vendor calls itself. Ask what happens after the employee reads the reply: if the interaction is finished, you need answering; if somebody now has work to do, you need tracking.
• The honest answer for most mid-size companies is both, in that order, six to twelve weeks apart. Answering first removes the volume that makes the queue unreadable.
• Products that claim both usually do one well. Decide which half you are actually buying before you look at a price.

The Request That Sat in a Shared Inbox for Nine Days

An employee emailed HR to ask whether her new address had gone through on the payroll system. It was a Tuesday. The message landed in a shared inbox that four people could see, which in practice meant none of them owned it.

Two of those four were on leave. The third read it, decided it belonged to payroll, and forwarded it without replying to the sender. The fourth never saw it at all. Payroll read it, decided it belonged to HR because the address change had been submitted through the HR system, and sent it back.

Nine days later the employee asked again, this time in a message to her manager, who escalated it as a payroll failure. It was not a payroll failure. Nobody had checked. The entire history of this request lived in four separate mailboxes with no shared state, and the question underneath it, whether a submitted address change appears on the next payslip or the one after, had a documented answer that nobody looked up.

Recommended Tools

Best tools for AI HR Tools

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

View all recommended tools

So the company had two problems in one email. The question was answerable from a document. The request was untracked. A chatbot would have solved the first in four seconds and left the second exactly where it was.

The Distinction Nobody Draws Before Buying

Every HR chatbot and every HR support product sits somewhere on a line between two jobs.

At one end: answering. Somebody asks a question, the system replies with information that already existed, and the interaction ends. Nothing has changed in the world. Nobody owes anybody anything. The value is that a person did not have to look it up and a second person did not have to type it out.

At the other end: actioning. Somebody asks for something, and the system records that a request exists, who owns it, what state it is in, and when it stopped being somebody's problem. The value is that the request cannot quietly disappear into a shared mailbox.

These sound adjacent. They are built differently all the way down. An answering tool is a retrieval problem: find the right paragraph, phrase it for this question, measure whether the answer was right. An actioning tool is a state machine: who owns this, what is it waiting on, what is the clock, who gets told when it moves.

A product can do both. Most do one well and the other adequately, and the adequate half is usually the one you hear about in the demo.

The Shape of the Mail HR Actually Gets

Before deciding which half to buy, count what you have. Not estimate. Count.

Take one month of HR inbound from whatever channel carries most of it, and sort each message into one of four piles.

Pile one, answerable from a document that exists. How many annual leave days do I have left, when does the new policy start, what is the notice period in my contract, who approves expenses over a threshold. The answer is written down somewhere. The employee could not find it, or did not know to look.

Pile two, answerable only from personal data. What is my remaining balance specifically, has my address change gone through, what did my last payslip deduct and why. There is a correct answer, but it lives in a system of record rather than a document, and it differs per person.

Pile three, a request for somebody to do something. Please change my bank details, please book me on this course, please correct my holiday balance, please send a reference. Something in a system has to be altered by somebody with permission.

Pile four, a conversation with a human being. A grievance, a bereavement, a dispute about pay, a disclosure, anything where the person is in difficulty. These must never be automated and they are not what either product category is for.

In the companies where this has actually been counted, pile one is the large majority and pile four is a handful. At one 340-person services business the split across one month of 612 messages was 71 per cent pile one, 12 per cent pile two, 14 per cent pile three and 3 per cent pile four. That company had been shopping for a case management system, which addresses pile three, the second smallest pile.

What People Actually Need, Which Is Not What They Ask For

Why does nobody read the handbook?

Because reading is the wrong verb. Nobody reads a handbook. They have one question and they want one paragraph, and the handbook makes them find which of eleven documents contains it and then which of forty sections. A search box helps only if they guess the vocabulary the document uses, which they usually do not. An answering tool fixes this and a ticket system does not even try.

Why do the same questions keep coming back?

Because the answer arrived in a private channel. Every reply HR sends by email teaches exactly one person, and the next person who asks starts from nothing. The knowledge exists forty times in forty sent-items folders and nowhere a second person can reach. This is the pure case for answering, and it is the single commonest reason companies in this bracket go shopping.

Why do requests go missing?

Because nothing in a shared inbox has an owner or a state. An email is read or unread, which tells you nothing about whether anybody intends to act on it. Three people can read a message and each assume one of the others has it. No amount of answering quality fixes this; it is the pure case for tracking.

Why is HR always the last to know?

Because the volume of pile one buries the signal in piles two and three. When a team processes 600 messages a month by hand, the fourteen that matter arrive looking identical to the 500 that do not. Removing the answerable volume is what makes the consequential requests visible, which is the real argument for doing answering before tracking rather than instead of it.

Why does the HR team feel like a help desk?

Because for most of the week it is one. That is not a complaint about the work being beneath anybody. It is a statement about where the hours go: a team hired to design pay structures and handle difficult conversations spends its mornings retyping the leave policy. The hours do not come back on their own.

The Three Product Shapes, Honestly

Shape one: an answering assistant over your documents

You point it at a handbook, a few policy documents and whatever else is written down. It answers questions in natural language, citing the document it drew from. It does not know who the asker is in any deep sense and it cannot change anything.

When this is right. Pile one dominates, which for most companies under about 800 people it does. You have documents that are current enough to answer from. You want the first version live in weeks rather than quarters.

When it fails. When the documents are wrong, in which case you have industrialised a wrong answer. When your actual pain is untracked requests, in which case you have made the queue better informed and no more tracked. And when somebody mistakes it for a system of record, which it is not: it can tell you what the leave policy says and it cannot tell you your balance unless something connects it to the system that holds the balance.

Shape two: a case or ticket system for HR

Every inbound request becomes a record with a category, an owner, a state and a clock. You get queues, assignment, escalation and reporting on how long things take.

When this is right. Requests are genuinely going missing. You have enough volume in pile three that losing one has consequences. Somebody needs to answer the question "how long do we take to action a change" with a number rather than an impression. Investigations and employee relations work especially need this, because those have to be auditable in a way an email thread is not.

When it fails. When you point it at pile one. Ten thousand tickets that all ask about annual leave is not a solved problem, it is the same problem with better metrics on it. Teams in this position end up proud of a four-hour first response time on work that should never have reached a human being at all.

Shape three: a platform that claims both

The large service management suites offer a knowledge base with AI answering on top of a full ticketing engine. On paper this is the whole answer.

When this is right. You are large enough that the per-agent pricing is not the deciding factor, you already run the same platform for IT, and you have somebody whose job includes configuring it. At 2,000 people with an existing service management deployment this is usually correct and the alternatives look like fragmentation.

When it fails. At mid-size, on two counts. The pricing is per agent, which means the half you use most (everybody asking questions) is free while the half you use least (your three HR coordinators) carries the bill, and separately the answering quality in a suite is often the weaker half of the product. Implementation is measured in quarters. A 90-person company does not need a service management deployment to stop retyping the leave policy.

Five Questions That Decide It

What happens after the employee reads the reply? If the interaction is over, you are buying answering. If somebody now has a job to do, you are buying tracking. Run this test against twenty real messages and the answer stops being a matter of opinion.

Could the answer have been copied from a document? If yes, every one of those is a message an answering tool removes and a ticket system merely files. If no, and the answer needed a lookup in a system or a decision by a person, answering will not touch it.

Is anything actually getting lost? Be specific. Name three requests in the last quarter that went missing or went late, and say what it cost. If you cannot name three, your tracking problem may be smaller than the vendor assumed when they built the deck. If you can name thirty, stop reading about chatbots.

Who would own the queue? A ticket system without an owner becomes a second inbox with worse ergonomics. If no named person is accountable for the queue being empty, buying the queue makes things worse, not better. This kills more case management deployments than price does.

Are your documents good enough to answer from today? Not after a rewrite you intend to do. Today. If the handbook is two years stale, answering will confidently serve stale policy to everyone at once, and that is worse than the status quo where it was only wrong when somebody happened to ask.

The Options

Matram, named below, is owned by the same people who publish HROpsLab. Its limitations are stated as plainly as everybody else's, and on this particular question those limitations are the point of the article rather than a footnote.

Matram

An answering agent trained on documents you supply. It answers in the asker's language, cites what it drew from, and has a strict mode that makes it decline rather than guess when the corpus does not cover a question. Pricing is flat at $29, $69 and $199 a month with unlimited seats, which matters here because the population asking questions is everybody and per-seat pricing taxes exactly that.

Its cons are the subject of this article. It has no free tier. It answers and does not action tickets, so a request to change a bank detail produces a correct explanation of the process and no change to any bank detail. And it is not an HR workflow platform: there is no case record, no owner, no state, no clock. If pile three is your problem, this is the wrong half of the product line and the flat pricing does not change that.

Freshservice

A service management platform with an HR use case, ticketing as its core and Freddy AI as an answering layer on top. Starter, Growth and Pro run at $19, $49 and $99 per agent per month, with the Freddy AI add-on at $29 per agent per month on top.

Honest assessment: this is the strongest fit if you genuinely need both halves and you already run it for IT. The answering layer is competent rather than best in class. The per-agent model means the cost scales with your HR team rather than your headcount, which is cheap at three coordinators and gets expensive as a shared service team grows.

Zendesk

Mature ticketing, strong reporting, and an AI layer sold separately. Suite Team is $55 per agent per month and the Copilot add-on is $50 per agent per month, so an agent with the AI layer is $105 a month. At twelve agents that is $1,260 a month and at twenty it is $2,100.

Honest assessment: the ticketing is excellent and it was built for customer support, so the HR framing is a configuration rather than a native fit. The answering half is the add-on, and pricing it per agent when the askers are your whole workforce is the structural mismatch in this category.

Leena AI and Moveworks

Both are built for exactly the shape this article describes: answering plus actioning, aimed at enterprise HR and IT service delivery, with the identity of the asker as a core assumption rather than an afterthought.

Honest assessment: neither publishes a price. Both are enterprise sales with implementation attached, which is appropriate at several thousand employees and heavy at 200. If you are in the bracket where these make sense you probably already know it, and if you are not, the evaluation itself will cost you more weeks than a smaller deployment would take to go live.

HR Acuity

Case management for employee relations and investigations specifically: intake, documentation, aftercare, the audit trail. Not a chatbot and not trying to be. It publishes no price and sells by demo.

Honest assessment: this is pile three and pile four, done properly, for the subset of HR work where an auditable record is the whole point. It does not address repetition at all. Naming it here is to make the point that HR support software spans products with almost nothing in common.

Crisp

A shared inbox and messaging platform with a chatbot layer, priced per workspace rather than per seat: a free tier, then $45, $95 and $295 a month.

Honest assessment: the workspace pricing is unusual and favours a team that wants several people in one inbox without a per-head bill. It is a support tool adapted to HR rather than built for it, the knowledge layer is lighter than a dedicated answering product, and it sits closer to the shared-inbox-done-properly end than to either pure category.

SiteGPT

A document-trained answering agent aimed primarily at public websites. Starter and Growth are $59 and $129 a month billed monthly, or $468 and $948 per year billed yearly.

Honest assessment: strong at the answering half, with no actioning at all and a public-surface assumption that sits awkwardly with internal HR use. The annual plans work out near $39 and $79 a month billed yearly, and quoting either without that qualifier misstates them.

On language coverage it publishes 95+ languages, which is the same figure Matram publishes, so neither of them leads on that dimension and it should not decide the comparison either way.

The Comparison

Read the first two columns before the third. A cheaper product that does the wrong half is not cheaper.

The Decision Table

The Pile Two Problem Both Halves Miss

Pile two deserves its own section because it is where both product categories quietly fail and where most of the disappointment comes from.

How many days do I have left is not a document question. The policy document says how entitlement accrues, and it cannot say what your balance is. An answering tool over documents will either decline, which is correct and unsatisfying, or explain the accrual rules at you, which is correct and infuriating. Neither is the answer the person wanted.

It is not a ticket question either. Turning a balance enquiry into a tracked request with an owner and a four-hour response target is an enormous amount of ceremony for a number that a system already knows.

The real answer to pile two is self-service in the system of record: the employee can see their own balance, their own payslip, their own submitted changes, without asking anybody. If your HRIS has that and people are still asking HR, the problem is that they cannot find it or do not trust it, and the fix is a link and a sentence rather than a new product.

Where an answering tool helps with pile two is at the boundary. It can say, accurately, that your balance is in the people system under My Time, here is the link, and the policy on carry-over says this. That is a real improvement over silence. It is not the same as knowing the number, and a vendor who implies otherwise during a demo is describing an integration you have not scoped.

Sequencing, If You Need Both

Most companies in the 200 to 800 bracket need both halves eventually. The order matters more than the products.

Answering first, for one specific reason. It removes pile one, which is the majority of the volume. A queue with pile one still in it cannot be read: everything looks the same, response time averages are meaningless because they mix a four-second lookup with a three-day investigation, and the team cannot tell whether it is busy or merely interrupted. Take out the repetition and the remaining queue is small enough to see.

Then measure for a month before buying tracking. With the answerable volume gone, count pile three again. The number will be lower than it was, and it may be low enough that a shared inbox with one named owner and a simple convention is genuinely sufficient. Several companies that budgeted for case management discovered they had eleven real requests a week.

Then buy tracking for what is left, sized to that number rather than to the original volume. Three categories, one owner, one escalation rule. Teams that start with twenty categories and a workflow diagram end up with twenty mostly-empty queues and a convention nobody follows.

The reverse order is common and it is the expensive mistake. Tracking first gives you an accurate measurement of a problem you were about to remove, and a configuration sized for volume you will not have in three months.

The Handoff, Which Is Where Both-Halves Deployments Actually Fail

Everything above argues for buying both halves in sequence. Almost nobody specifies the join between them, and the join is where the employee experience breaks.

Here is the failure in one sentence. The assistant answers a question, the employee says that is not quite it, and nothing happens. No person appears. No record is created. The conversation simply ends, and the employee goes back to email having spent two minutes learning that the new thing does not work. That is the moment adoption dies, and it is a design decision somebody forgot to make rather than a limitation of either product.

What the handoff has to carry. When a conversation becomes a request, three things must survive the transition: what the person actually asked, in their own words rather than a category label; what the assistant already told them, so the human does not repeat an answer that has already failed; and who they are, so nobody has to ask for a name and a start date that the system already knows. Lose the first and the human starts from zero. Lose the second and the employee gets the same unhelpful paragraph twice, this time from a person, which reads as not listening. Lose the third and you have added a step rather than removed one.

What triggers it. Resist the temptation to escalate on low confidence alone. A confidence score tells you whether the model found a match, not whether the person is satisfied, and the two diverge in both directions: a confident answer to the wrong question scores high, and a correct answer to an unusual phrasing scores low. The signals worth acting on are an explicit request for a person, a second attempt at the same question, any question that touches pay, grievance or personal circumstance, and the strict-mode refusal that says the corpus does not cover this. Two failed attempts is the practical ceiling. A third try is not persistence, it is the system wasting somebody's afternoon.

What the employee should see. One sentence that admits the limit and names what happens next, with a reference they can quote. Not an apology, not a form, and never a dead end. The difference between a good handoff and a bad one is whether the person leaves the conversation knowing somebody now has their request.

If you are buying both halves, write this handoff down before you buy either. It is four decisions on one page, and it is the part no vendor demo covers because it sits between two products rather than inside one.

What Each Half Needs From You

Neither product works out of the box, and the work they need is different, which is worth knowing before you commit a quarter to one of them.

Answering needs documents. Specifically it needs documents that are current, that state one fact per paragraph, and that have headings resembling the questions people ask. A handbook written as continuous prose with nine-sentence paragraphs will produce mediocre answers from the best retrieval available, because the unit it has to return is too large to be an answer. Budget real weeks for restructuring, and treat that work as the deliverable rather than as preparation for the deliverable.

Tracking needs decisions. Categories, owners, states, escalation, and a definition of done for each category. These are organisational decisions dressed as configuration, and that is why case management deployments stall: somebody has to decide who owns a bank detail change and what happens if they are on leave, and nobody wants to be the person who decides. The software cannot make that decision for you and it will not work until somebody does.

Both need somebody named. Not a committee and not a steering group: one person who is accountable for the thing working, with the time to do it. This is the most reliable predictor of whether either deployment is still in use a year later, and it is the one thing no vendor can sell you.

What Getting This Wrong Costs

The direct cost is a wasted subscription, and that is the smallest part of it.

The real cost is a year. A company that buys case management to solve repetition spends six months implementing it, a few months discovering it has not reduced the volume, and then has to make the case internally for a second purchase in the same category, to a finance function that has just been told this was the fix. The second business case is much harder than the first would have been.

And there is a credibility cost inside HR. The team told everybody this would make HR easier to reach. If what arrived was a form that produces a ticket number for a question that used to get an answer, adoption drops and the shared inbox quietly comes back, because people route around systems that make their day longer. You then have both the system and the inbox, which is worse than either.

Ask the question the other way around. If you removed every repetitive question from HR's week and changed nothing else, would the team's real problems be solved? If yes, buy answering. If the answer is that you would still be losing requests, you have learnt something specific and cheap.

When You're Ready to Add the Other Half

The signal that you need tracking after answering is specific: a request goes late, somebody asks where it got to, and nobody can say. Not a general feeling of disorganisation. A named request, a measurable delay, and no way to reconstruct what happened.

The signal that you need answering after tracking is equally specific: your queue is full of tickets whose resolution is a copied paragraph. If a sample of fifty closed tickets shows thirty closed with the same four answers, you are using a state machine as a search engine.

Either way, do not buy the second half from the first vendor by default. The suite discount is real and so is the cost of the weaker half, and in this category the weaker half is usually the one bundled in. Price the add-on against a dedicated product honestly, including what the per-agent model does as the team grows, and remember that the population asking questions is your entire workforce while the population closing tickets is three people. Any pricing model that charges you for the second group to serve the first is working in your favour, and any model that charges for the first is not.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements.