HR Chatbots: Why They Fail, and What Separates the Ones That Work

In 2017 IBM launched an HR chatbot called AskHR. It was built by a company that sells this technology for a living, deployed to a workforce that works in technology, and answering questions the bot was perfectly capable of answering.

Almost nobody used it.

Their CHRO, Nickle LaMoreaux, has been unusually candid about what happened next. The company decided the problem was employee reluctance, so in 2018 it told more than 20,000 workers that HR would no longer answer their questions directly because the bot was now the route. Satisfaction with the HR department fell from +19 to −35.

Her diagnosis afterwards is the line worth keeping: the technology was there, the tool was there, but the behavior wasn't there. They had treated it as a technical change.

IBM stuck with it and eventually got there, but it took years and a change of approach rather than a better bot.

The story is nearly a decade old, and the technology has moved a long way since. It stays interesting because the failure was never technical, and neither was the fix. A chatbot that people do not use is not a broken chatbot. It is a chatbot that gave someone a reason not to come back.

Most of the reasons below look like capability problems and are really adoption problems wearing a capability costume. An employee tries a bot, it gets something wrong, or cannot do the thing they needed, or does not understand a question that was obviously in scope and they never open it again. One bad interaction is usually all it takes.

Based on almost a decade of implementing HR AI successfully, here is what causes that, and what to look for instead.

1. Accuracy, and answers grounded in your knowledge

Nothing destroys trust faster than a confident wrong answer about someone's pay, leave or benefits.

A general model does not know your parental leave policy, your notice periods, or which of your three expense tools the Denmark office uses. If it answers anyway, plausibly, fluently, and incorrectly - the employee acts on it, discovers the error later, and tells their team. Recovery from that is expensive and slow.

An HR chatbot has to answer from the knowledge you have given it and stay inside that scope. It should cite the document and clause it used, so the employee can check and so HR can prove what was said. And when the knowledge does not cover the question, the correct behavior is to say so and route to a person rather than improvise.

The quality of that grounding matters as much as its existence. Retrieval that returns the nearest-looking paragraph is not the same as retrieval that reconciles two documents that disagree, recognizes a question spanning three sources, or notices that a policy was superseded at the last enrolment.

There is a second half to this that most products ignore. Every question the system could not answer is a hole in your knowledge base, and nobody has ever produced that list by hand. A good system tells you what it was asked and could not answer, ranked by how often it came up, so the gaps you fix are the ones costing you the most tickets. Better still if it helps you close them by drafting the missing policy from what does exist, from how your HR team has been answering the question, and from the shape of the policies you already have. The gap list is useful; a gap list with a draft attached is what actually gets it fixed.

What to test: ask a question your knowledge base genuinely does not cover, and watch whether it declines or invents. Then change a source document and ask again, to see whether the answer follows. Then ask to see the list of unanswered questions from the last month.

2. Answering is not enough

Most HR chatbots do one thing: they respond. The employee asks about their remaining leave, gets the policy, and then goes off to a different system to actually book it.

The request has not been resolved. It has been explained.

What employees want from a conversation is the outcome. Submit the leave. Update the address. Raise the case. Chase the approval that has been sitting with a manager for four days. Pull the time records and work out why the overtime payment differs from what was expected.

That requires an agentic solution rather than a conversational one, something that can trigger an automation, open a ticket or a case, investigate an issue across systems and come back with an answer, monitor a workflow in progress, nudge the people holding it up, and assist the HR team on the requests that do reach them.

What to test: ask for something with a consequence and see whether anything changes in your systems when the conversation ends. If the only output is text, it is a chatbot in the old sense.

3. Scope that is too narrow

Some HR chatbots handle a defined list of topics well and everything else not at all. Benefits, yes. Payroll timing, yes. Anything about a secondment, a visa, a grievance, an equipment request that turns out to be IT's - no.

Employees do not know or care where those boundaries are. They arrive with whatever they have, and each miss teaches them the tool is unreliable. Three misses and they stop trying, including for the questions it would have answered well.

A bot that answers 40% of questions brilliantly and refuses the rest gets used far less than the arithmetic suggests, because people cannot predict which category they are in before they ask.

What to test: bring twenty real questions from your actual queue, including the awkward ones, and see how many get a useful response.

4. Every channel, including the ones without a screen

Employees are not all sitting at a desk with a browser open.

An HR chatbot needs to work in Teams and Slack, in the web portal, in a mobile app, over email, and on the phone. The last one is the one most products skip and the one that matters most for coverage, because the population it serves is the population least served today: the factory floor, the depot, the ward, the store, the site. People with no corporate laptop, often no company email, and a shift pattern that does not overlap with HR's working hours.

There is also a smaller case worth remembering. An employee locked out of their account cannot open a chat window to ask for help getting into their account.

What to test: ask what a deskless worker does at 6am, and whether the answer involves a phone number that reaches the same intelligence as the chat window.

5. Answers that fit the person asking

An IT policy is usually one policy. HR policy is many policies wearing one name.

Parental leave depends on jurisdiction, tenure and employment class. Notice periods differ by country. Benefits eligibility differs by hours worked. What a contractor is entitled to is not what a full-time employee is entitled to, and what applies to a factory worker in Ohio does not apply to a desk worker in Germany.

A chatbot that returns the same knowledge article to everyone is returning the wrong answer to most of them, confidently. The system has to know who is asking, their location, employment class, tenure, entitlements, and then answer for that person rather than for an average employee who does not exist.

Language belongs here too. Multilingual support is not a translation feature bolted on top; it is part of answering the person in front of you. An employee asking in Polish about a Polish employment contract should get the Polish policy, in Polish, not a machine translation of the American handbook.

What to test: ask the same policy question as two different employees from different country, different employment class. If both get the same article, the product cannot personalize, whatever the datasheet says.

6. Room to grow beyond what it shipped with

Every organisation has problems nobody else has. A specific approval chain. An industry-regulated process. An overtime calculation that depends on a union agreement. A benefits scheme that exists in one country.

If solving each of those requires a professional services engagement, the product has a ceiling and you will meet it inside the first year.

This is where agents matter, and where the word is worth being precise about. An agent is a piece of capability built for a specific job like reading a garnishment order and working out what applies, reconstructing why an overtime payment differs from what was expected, running the eligibility check that your benefits scheme needs. It reasons over the situation, uses the systems it has been given, and acts.

What you want is somewhere to build those yourself. In Rezolve.ai that is Agent Studio, and it works across three tiers. Foundational agents handle the universal decisions in any conversation like routing, choosing the right knowledge, composing a cited answer, gathering the detail that is missing, forming a clean ticket. A marketplace of proven agents can be cloned and adapted rather than built from nothing. And underneath both, custom agents can be built for the situations only your organisation has, against your systems and your policies, without a project.

The three tiers matter more than any single one. Most products offer one and imply the others, and the gap shows up six months in, when the thing you need is not in the catalogue and building it is somebody else's quote.

This is also what determines whether the deployment keeps improving after go-live or stops at the feature list you bought.

What to test: describe a problem unique to your organisation and ask who builds the solution, how long it takes, and what it costs. Then ask to watch one get built.

Back to the adoption problem

Every one of those six is a capability question, and every one of them decides adoption.

An employee who gets a wrong answer, or an explanation when they wanted an action, or a refusal on a question that was obviously in scope, or who cannot reach the thing at all from a factory floor, or who gets the American policy when they work in Warsaw - each of those people has learned something about the tool, and what they have learned is not to bother.

IBM's recovery is instructive on the other side of it. What changed was not that the bot got smarter in one release. They started listening to feedback, introduced it gradually rather than by decree, and let people find the uses that worked for them. The capability had to be there. It just was not sufficient on its own.

So a deployment plan needs both halves. Get the capability right, then treat the rollout as a change in how people work rather than a piece of software being switched on. Communicate before it launches, give people reasons to try it that are genuinely useful, measure adoption rather than deflection, and fix what the first month tells you.

One more thing IBM got right, and it belongs in any HR deployment: AskHR routes to a person for sensitive matters like performance concerns, misconduct, etc. Deciding what should never be automated is part of designing the thing, not a limitation to apologize for.

Escalation deserves more attention than it usually gets, because it is where the worst experiences happen. Two things separate a good handover from a bad one.

The first is live chat, staffed by a person, reachable from inside the same conversation - not a ticket that gets answered tomorrow. The employee stays where they are and a human joins them. Real-time translation belongs here too, so that an employee writing in Polish and an HR partner answering in English can hold one conversation rather than two. Language should not decide who gets a fast answer.

The second is harder and more valuable: the system recognizing, at the moment it happens, that this particular message is sensitive. A queue sorted by SLA treats "when does payroll run this month" and "my manager has been retaliating since I raised a concern" identically until a human opens them. An agent making that assessment on the spot like recognizing the exposure, routing out of the normal queue to a named person, and doing it in seconds rather than at the next triage pass is the difference between a situation handled and a situation that becomes a legal matter.

Both of those are capability. Both of them are also, in the end, what makes people willing to bring HR the difficult things at all.

The products worth looking at

One thing to know before you shortlist: this market consolidated fast. Aisera was acquired by Automation Anywhere in November 2025. ServiceNow closed its acquisition of Moveworks that December. Espressive was acquired by Resolve in September 2025, and espressive.com now redirects to resolve.io. Several names people still search for no longer exist as independent companies, and the products behind them are being folded into larger portfolios. Ask any vendor on your list who owns them, what changed after the deal, and who owns the roadmap now.

Rather than a grid of ticks, the six sections above are the comparison. Take them into a demo and run the tests. Six questions will separate any two products on this list faster than any datasheet:

Where do the answers come from, and can it show me the clause? Grounding is claimed universally. Citation is not.

What changes in my systems when the conversation ends? If the answer is nothing, you have bought an explanation engine.

What happens with a question outside its scope? And how much of my real queue falls outside it.

What does a deskless employee do at six in the morning? If the answer does not involve a phone number, a large part of your workforce is not covered.

Does a contractor in Warsaw get a different answer from a full-time employee in Ohio? Ask the same question as two different people and compare.

Who builds the thing I need that you do not have? If the answer routes through professional services, add it to the total cost.

We have an obvious interest in how that comparison goes, so treat this section as an argument rather than a survey, and run the tests yourself rather than taking anyone's word for it, ours included.

One honest boundary while we are here: if your primary requirement is formal employee relations case management with investigation workflow, evaluate that specifically rather than assuming any product on this list covers it well.