How to Tell People a Bot Now Answers HR Questions

TL;DR

• The announcement decides adoption more than the configuration does. A well-built assistant introduced badly gets used for holiday balances and nothing else.
• Say what it cannot do, by name. A list of three honest limits produces more trust than any claim about capability, because every limit you omit gets discovered by somebody at the worst moment.
• Answer the privacy question in the announcement rather than waiting to be asked. Whether managers can see the questions is the thing people actually want to know, and silence reads as yes.
• Three sentences to leave out: that it is powered by AI, that it will save the HR team time, and that it is available 24/7 as a headline benefit.
• Launch to a small group first, not because of technical risk but because the first forty real questions will change your document set and your refusal wording.
• Name a person in the announcement. A tool introduced by a function is nobody's; one introduced by a named owner has somebody to tell when it is wrong.

The Launch Email That Reduced Usage

A 600-person company sent a launch email that did almost everything wrong while being entirely well-intentioned. It opened by announcing an exciting new AI-powered HR chatbot. It said the assistant could answer any HR question, instantly, day or night. It explained that this would free up the HR team to focus on more strategic work. It included a link and a cheerful closing line.

Usage in week one was high, which the team took as success. By week four it had fallen by more than half and stabilised at a level roughly matching the number of people checking holiday balances.

The post-mortem found three distinct causes, all in the email.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

Any HR question set an expectation the assistant could not meet, and the first people to test it did so adversarially, because that is what an unrestricted claim invites. They asked about pay reviews and redundancy and got nothing useful, concluded it did not work, and told their teams.

Free up the HR team told everybody the purpose of this was to reduce HR's workload. Employees are not hostile to that, and they also reasonably inferred that the assistant existed to keep them away from HR, which made it the thing you used when you did not want to bother anybody rather than the thing you used first.

Nothing about privacy at all. The question of who could see the conversations was raised in three different team channels in the first fortnight and answered by speculation, because the announcement had not addressed it. The speculation settled on the assumption that HR could see everything, which was true, and which nobody had decided to tell people.

So the configuration was fine and the content was good. The announcement set three expectations that the product then failed, and recovering from that took a second launch.

What the Announcement Is Actually For

It is not a feature description. It has three jobs, and most launch emails do only the first.

Tell people it exists and where. Necessary and the easy part. One line and a link.

Set an accurate expectation of scope. This is the job that decides whether the first interaction succeeds. People form a judgement in one or two questions, and which questions they choose is determined entirely by what you told them it was for. An announcement that says it answers questions about leave, pay dates, benefits and policies gets asked about those things and performs well. An announcement that says it answers any HR question gets asked about a grievance and fails.

Answer the questions people will not ask you. Who can see this, does it count against me, is it replacing the HR team, what happens if it gets something wrong. These get asked in team channels rather than to HR, and whatever the answer is there becomes the organisation's understanding. Answering them in the announcement is the only chance to shape that.

The third job is the one nobody plans for and the one that determines whether the system is used for anything that matters.

Say What It Cannot Do, by Name

This is the counterintuitive part and it is the highest-return paragraph in the announcement.

List three things it cannot do. Specifically, by name, in the launch message. Not a disclaimer at the bottom and not a general caveat about AI being imperfect, which reads as legal cover rather than information.

It cannot see your personal data. It knows what the policy says about how leave accrues and it does not know your balance. This single sentence prevents the commonest disappointing first interaction in the entire category, because the balance question is what a large share of people will try first.

It cannot make a decision or action a request. It can explain how to change your bank details and it cannot change them. Saying this removes the second commonest failed interaction and also pre-empts the belief that the thing has authority over anybody's case.

It cannot help with anything sensitive, and will put you through to a person. Name the person or role. This is the limit that matters most, and stating it in advance converts what would feel like a failure into the system working as described.

Then one sentence on what to do when it is wrong, with a name attached. Every assistant gives wrong answers and the organisation's response to that is determined by whether there was a route for reporting it. With a route, a wrong answer is a correction. Without one, it is evidence the thing cannot be trusted, and that conclusion spreads much faster than any individual answer.

Teams resist this paragraph, because it reads as undermining the launch. It does the opposite. A limit you state is a specification and a limit somebody discovers is a defect, and the same fact lands completely differently depending on which it was.

The Three Sentences to Leave Out

Powered by AI

Mentioning the technology invites a judgement about the technology instead of about the usefulness. People have strong priors about AI, mostly formed elsewhere, and recruiting those priors into a question about whether your handbook is searchable is a cost with no benefit.

It also makes the thing sound experimental, which licenses dismissing it. Describe what it does: it answers questions about HR policies using the company's own documents. That is more informative, it is accurate, and it tells people the answers come from your policies rather than from the internet, which is the reassurance they actually need.

Say what it is if anybody asks, and do not lead with it.

This will save the HR team time

True, and the wrong audience for it. Internally it is the business case. In an announcement to employees it says the purpose of this is us, which reframes the tool as a barrier rather than a service.

The employee-facing benefit is different and better: an answer in seconds instead of a day, without having to decide whether the question is worth asking. That second clause is doing real work, because a meaningful share of unasked questions are unasked out of reluctance to bother somebody, and removing that is a genuine improvement people recognise.

Available 24/7

Harmless as a detail and misleading as a headline. Promoted to a benefit, it implies that out-of-hours support is the point, which sets up an expectation of help at 11pm that an answering tool over documents cannot meet in any meaningful sense for an urgent problem.

It also sits badly beside the sensitive-topic limit. Somebody in difficulty at midnight, told the system is available around the clock, discovers that what is available is a referral to a person who is not. Mention it in a list of practical details and do not build the announcement on it.

What People Will Ask in Team Channels

Can my manager see what I asked?

The first question, every time, and the one that decides whether anybody asks anything difficult. Answer it explicitly as a yes or a no. If the answer is anything other than a clean no, the honest version is still better than silence, because people will work it out and the discovery is worse than the disclosure.

Is this replacing people?

Asked quietly and widely, especially if the announcement mentioned saving HR time. The answer needs to be specific rather than reassuring: nobody's role is changing, and here is what the HR team will be doing with the time, named concretely. A general denial without that detail is read as a non-answer.

What happens if it tells me something wrong?

A reasonable question that most launches do not answer. The reply is a route and a name, plus the honest statement that it will sometimes be wrong and that reporting it fixes it for everybody. People are notably tolerant of error when there is a mechanism, and notably intolerant when there is not.

Do I have to use it?

Worth answering unprompted with a plain no. Mandating it produces resentment and compliance behaviour, and an assistant that works does not need a mandate. The one qualification worth adding is that HR may point people to it for common questions, which is true and better said in advance.

Is it reading my files or my messages?

People overestimate what these systems have access to, and the specific fear is that it is connected to their email or documents. State what it reads, which is the company's policy documents, and state what it does not. One sentence, and it closes a concern that otherwise circulates unchallenged.

Launch Small First, for a Content Reason

The case for a pilot here is not technical risk. It is that the first forty real questions will teach you things no internal test set does.

Real phrasing is different from test phrasing. Everybody who built the thing asks questions in the vocabulary of the documents. Employees ask in the vocabulary of their own situation, with typos, partial sentences and context the question does not state. A pilot is the cheapest way to collect forty genuine phrasings, and the document edits that follow are usually significant.

You will find out which limits need stating. The three limits above are the common ones. Your own organisation will have a fourth, and the pilot is where it surfaces, before it surfaces in front of everybody.

You will find out whether the refusal wording works. Written refusals always read fine to the person who wrote them. The pilot is where you learn that the sensitive-topic response sounds dismissive to somebody actually in that situation, which is not discoverable any other way.

Pick the group deliberately. One function of thirty to fifty people, chosen because they ask a representative range of questions rather than because they are enthusiastic about tools. An enthusiast group will not find the problems, because they will interpret failures charitably and work around them without telling you.

Two to three weeks is enough. Longer and the pilot becomes the deployment, with a second announcement that has to explain why it is now being launched again.

And tell the pilot group it is a pilot, explicitly. This changes what you get back. A group told they are testing something reports problems, because reporting is the point of their involvement. The same group told they have early access to a finished tool stays quiet about failures out of politeness, which is the behaviour that makes a pilot produce a clean result and no information. Ask them directly for the questions it got wrong, and ask at the end of week one rather than at the end of three, while they still remember.

Where to Put It, Which Matters as Much as What You Say

An announcement that lands perfectly and points at a link nobody can find again produces one week of usage. The placement decision gets made late, usually by whoever owns the intranet, and it deserves more attention than it gets.

The test is whether somebody can reach it without remembering anything. Not without remembering a URL. Without remembering that it exists. That means it has to live where people already are when the question occurs to them, which is almost never the HR section of an intranet.

In the tool people already have open. If your organisation runs a chat platform, this is the strongest placement by a wide margin, because the question occurs while somebody is already typing in that window. The gap between having a question and asking it is where most questions die, and this closes it almost entirely.

On the intranet home page, not the HR page. Somebody who has already decided to go to the HR section will find the handbook anyway. The person you are trying to reach has not decided anything; they have a question and three other things to do.

In the signature of every HR reply. Unglamorous and effective. The person asking HR a question by email is demonstrably somebody with HR questions, and a single line at the bottom of each reply reaches them at exactly the right moment with no campaign attached.

Not only in an email. The launch email reaches people once, and the population changes continuously through joiners, returners from leave and people who filed it unread. Any placement that depends on having read one message in one week will decay to the people who happened to be paying attention.

So decide the placement before writing the announcement, because the message has to point somewhere that will still be findable in March. A good email about a link buried three clicks into an intranet is a worse outcome than a mediocre email about something sitting in the chat tool everybody already uses.

The Options, and What Each Means for the Announcement

Matram, named below, is owned by the same people who publish HROpsLab. Its limitations are stated as plainly as everybody else's.

Matram

A document-trained answering agent, flat at $29, $69 and $199 a month with unlimited seats. Strict mode declines rather than guessing when the corpus does not cover a question.

For the announcement: unlimited seats means you can launch to everybody without a licence conversation, which removes a common reason to roll out by department and then never finish. Strict mode makes the honest-limits paragraph accurate rather than aspirational, because the product will actually decline. Its cons belong in your own announcement if relevant: it has no free tier, it answers rather than actioning tickets, and it is not an HR or ITSM workflow platform, which means the cannot-action-a-request limit is real and should be stated.

Freshservice

Service management with Freddy AI, at $19, $49 and $99 per agent per month plus a $29 per agent per month AI add-on.

For the announcement: because requests become tickets, you can honestly promise that a request will be tracked and get a reference, which is a stronger message than answering alone. Per-agent pricing means the announcement goes to everybody while the cost sits with your coordinators.

Zendesk

Suite Team at $55 per agent per month, Copilot at $50 per agent per month, so $105 per agent per month together. At twelve agents that is $1,260 a month.

For the announcement: the handover to a person is the most mature on this list, so the sensitive-topic sentence can name a real mechanism rather than an intention. Its defaults are customer-support shaped, which is worth checking before you describe the experience to employees.

Leena AI and Moveworks

Enterprise answering and actioning platforms. Neither publishes a price.

For the announcement: both know who the asker is, which enables personalised answers and makes the privacy paragraph harder to write, because the honest answer about what is stored against a name is longer. Plan that paragraph during implementation rather than the week before launch.

Crisp

A messaging platform with a chatbot layer, per workspace at a free tier and then $45, $95 and $295 a month.

For the announcement: a human can take over the conversation natively, which is a good thing to be able to promise. It is a shared inbox underneath, so be accurate about who on the team can see a conversation.

SiteGPT

A document and site-trained agent at $59 and $129 a month billed monthly, or $468 and $948 per year billed yearly. The annual plans work out near $39 and $79 a month billed yearly and should not be quoted bare.

For the announcement: anonymous by default, which makes the privacy paragraph short and strong. Thin handover options, so the sensitive-topic sentence has to point somewhere outside the product.

The Comparison

The third column is the one that shapes how your announcement reads, and almost nobody checks it before writing the email.

The Decision Table

Measuring Whether the Announcement Worked

Usage in week one measures curiosity. Nothing more. It will be high regardless of how good the message was, because people click a link in an internal email once, and reading success into it is how the company in the opening of this article concluded the launch had gone well.

Four signals tell you whether the announcement did its job, and all of them need two to four weeks.

The shape of week-four questions versus week-one questions. This is the clearest signal available. If week four is dominated by the topics you named in the announcement, the scope line worked. If week four is almost entirely balance lookups, the scope was set too narrow in practice or the privacy question stopped people asking anything else.

Whether anybody asked something sensitive. Not many, and the number should not be zero. A system that has never been asked a difficult question in a month at 500 people has not been trusted with anything, and the usual cause is the privacy paragraph being absent or unconvincing rather than people having no difficult questions.

Whether anybody reported a wrong answer. If nobody has, the route did not land. Wrong answers happen; silence means people are absorbing them rather than reporting them, which also means your gap log is understating the problem.

Return usage rather than total usage. How many people came back a second time in a different week. This is the only number that distinguishes a useful tool from a well-announced one, and it is usually available in whatever basic reporting the product offers.

So set the review at week four when you send the announcement, and write down what you expect to see. A prediction made in advance turns the review into a test rather than an interpretation, and the gap between the two is where the second message comes from.

The Announcement, in Order

A structure that works, and it is shorter than most launch emails.

One line on what it is and where. It answers questions about HR policies using our own documents, and here is where to find it. No technology, no adjectives.

Two lines on scope, with examples. Name four or five real topics: leave and how to book it, pay dates, benefits, probation, how to change a personal detail. Examples do more than a category description, because people pattern-match from them.

The three limits, by name. As above. Personal data, actioning requests, sensitive topics, with the route to a person named.

The privacy paragraph, under 120 words. What is stored, whether a name is attached, who can see it and whether managers can, how many days it is kept. Plain, second person, specific.

One line on what to do when it is wrong. A name and a channel, plus the honest statement that it will sometimes be wrong.

One line on what this does not change. Nobody's role, and HR is still reachable the same ways. This closes the replacement question before it is asked.

Signed by a person. Not the HR team and not an internal communications address. A name, which is the owner of the thing, so that reporting a problem has a destination. A message from a function is nobody's responsibility by construction, and the first wrong answer has nowhere to go except into the general view that the tool is unreliable. A name costs nothing and changes what happens in week three, when somebody gets a bad answer and has to decide whether it is worth mentioning to anybody.

Then stop. The commonest editing instinct is to add enthusiasm, and enthusiasm is what makes an announcement read like marketing and invites the scepticism that follows. A plain description of a useful tool with honest limits is the version people believe.

Two structural notes on the draft itself. Put the scope examples above the limits, because somebody who reads only the first third should come away knowing what to use it for rather than what it refuses. And keep the whole thing under about 300 words, which is achievable with the structure above and is roughly the ceiling for an internal message anybody reads to the end. Every launch email that fails this test fails it by adding context about the project rather than information for the reader, and the project context belongs in a separate note to the people who need it.

One last check before sending: read it as somebody who has a difficult question today. Does the message tell them, in the first thirty seconds, whether this thing is safe to ask and who sees it? That is the reader whose behaviour the announcement actually determines, and they are never the reader it gets drafted for.

Briefing the HR Team, Which Happens Before the Announcement

The group most likely to undermine the launch is the HR team, not out of resistance but because nobody briefed them and they are the ones everybody asks about it.

Three versions of the story circulating inside a five-person HR function is enough to unsettle a rollout, and it happens easily. One person describes it as a search tool, another as something that will reduce their workload, a third mentions they are not sure it is accurate. All three conversations happen in corridors and each is more persuasive than an email, because they come from the function that owns the thing.

So agree five answers on one page, before the announcement goes out.

What it is for, in one sentence, worded identically to the announcement so that the two do not diverge. If the team's description is broader than the announcement's, the broader one wins, because it arrives in person.

What happens to your own work. Say it concretely and honestly. Fewer repeated questions, same number of difficult ones, and here is what the time goes to. A vague answer here produces anxiety that leaks into how the team talks about the tool.

What to do when somebody says it gave them a wrong answer. The specific behaviour: take the question, pass it to the named owner, and answer the person properly. Not defend the tool, and not agree that it is unreliable. Both of those happen when nobody has said what the right response is.

Whether to point people to it. Yes, for common questions, and the wording matters. Pointing somebody to the assistant for a question about a bereavement is the single worst thing anybody in the HR team can do with it, so say which categories are fine and which are never.

What the team can and cannot see. They will be asked this, probably first, and an HR coordinator guessing at the answer is how the privacy story gets set. Give them the same paragraph the announcement uses.

That page takes half an hour to write and twenty minutes to walk through. It is the cheapest thing in this article and it prevents the failure mode where the announcement is accurate and the organisation's understanding comes from somewhere else.

What Getting This Wrong Costs

The direct cost is a relaunch, which is harder than a launch. The second message has to explain why the first was wrong without saying so, land with people who have already formed a view, and overcome the specific belief that this thing does not work. Expect it to recover less than half of the lost usage.

The quieter cost is the questions that never get asked. An assistant that people use for holiday balances and nothing else looks fine on volume and misses everything expensive: the benefits question somebody guessed at, the policy somebody assumed, the difficult thing somebody decided not to raise. None of those appear in a report, and the gap log will be correspondingly thin, which makes the deployment look healthy while delivering a fraction of the value.

And there is the damage to the next thing. An internal tool that launched with an overclaim and underdelivered sets the organisation's expectation for the following one, and the next announcement from the same function starts from a deficit. That is the real argument for the honest-limits paragraph: it is cheaper to spend a little credibility on stating a limit than to borrow a lot against a claim.

Ask it this way before sending. If somebody tries the three hardest things in the first five minutes, does this message mean they get what they expected? If not, the message is wrong, not the product.

When You're Ready to Go Beyond the Launch

Two follow-ups, both worth more than the launch email and both usually skipped.

A short message at week four, saying what changed. Here are the five things people asked that we could not answer, here are the documents we wrote as a result. This does two things at once: it proves the reporting route works, and it recruits people into improving the thing rather than judging it. Deployments that send this message have measurably better gap logs, because people start reporting problems when they can see that reporting produces changes.

A line in the onboarding pack. Every new joiner is the highest-value user this system has, because they have the most questions and the least idea who to ask. Most rollouts announce once to the existing population and then rely on new people discovering it, which means the group that benefits most gets no introduction at all. One line in the first-week material, with the same three honest limits, and the launch keeps working for everybody who arrives afterwards.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements.