Who Can Read the Questions Your Staff Ask the Bot?

TL;DR

• The question log is employee data. Somebody asking about flexible working, long-term sickness or a grievance procedure has disclosed something about their situation, and that disclosure is now stored.
• Most deployments answer the access question by accident. Whoever set the tool up has admin rights, which means whoever set it up can read everything, and nobody decided that.
• Aggregate reporting is the useful part and it is safe. Per-person question history is where the harm is, and almost nobody needs it.
• The report that should never exist is a list of who asked about what. If it can be produced, somebody will eventually ask for it, and the awkward refusal is harder than the earlier design decision.
• Retention of ninety days covers every legitimate operational use. Indefinite retention is the default in most products and the default is wrong.
• Tell employees what is stored and who can see it, before launch, in one paragraph. Adoption depends on it more than on answer quality.

The Report Somebody Asked For

Six weeks after a company of 410 people launched an HR chatbot, a director asked a reasonable-sounding question. Could they see which employees had been asking about the flexible working policy, because a reorganisation was coming and it would be useful to know where the resistance was.

The tool could produce it. The admin console had a conversation log with user identifiers attached, searchable by keyword, exportable. Four clicks.

The HR manager who had set the thing up said no, which was correct and cost her something, because she had to explain why to somebody more senior without a policy to point at. There was no policy. Nobody had thought about it. The access rights were whatever the product shipped with, and the product shipped with full visibility for whoever created the account.

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

What made it worse is that the request was not malicious. It was a manager reaching for data that was visibly available to answer a question about his own business. The failure was upstream of him: a system had been installed that could produce that report, and nobody had decided whether it should be able to.

So the question is not whether somebody will ask. The question is whether you have decided the answer before they do.

What Actually Gets Stored

Before deciding who may read it, know what there is to read. Most teams have never looked.

The question text, verbatim. Everything typed, including the parts people regret. Half-finished questions. The thing somebody started asking before deciding against it and rephrasing. Typos that reveal distress. People type differently to a machine than to a colleague, more freely, and the log holds all of it.

An identifier. Whether this is a name, an email, an employee number or an anonymous session token is the single most consequential setting in the product and it is usually set to whatever makes the integration easiest.

A timestamp. Which in combination with the question is more revealing than either alone. A question about compassionate leave at 2am is a different piece of information from the same question at 11am.

The answer, and whether it was marked unhelpful. Operationally this is the valuable part and it carries the least personal information.

Often, a conversation thread. Several questions in sequence from one person, which is far more revealing than any single question. Three questions about sickness absence, notice periods and references, asked in one session, is effectively a disclosure that somebody is leaving.

That last point is the one people miss. Individual questions look innocuous. A session is a narrative.

Read down the two columns. The fields with the most operational value are not the sensitive ones, which is the whole argument of this article.

The Distinction That Resolves Almost Everything

There are two different things people mean by looking at the logs, and conflating them is what produces bad arrangements.

Aggregate analysis. What topics are people asking about, how often, how many questions went unanswered, which documents are failing. This is the work that makes the deployment better, it is genuinely necessary, and it needs no identifiers at all. The question "what did people ask about most this month" and the question "who asked" are separable, and separating them costs nothing.

Individual history. What has this named person been asking. This is where every harm in this article lives, and the honest finding is that almost nobody has a legitimate need for it. Not HR, not managers, not the person running the tool.

There are exactly two situations where individual history is defensible. One is an investigation where the questions are material evidence and there is a documented process, which is rare and should run through whatever governs access to other employee records rather than through a chatbot admin console. The other is a specific support request, where somebody says the assistant gave them a wrong answer yesterday and asks you to look at it, which is consent given in the moment for one conversation.

Everything else is curiosity with a business justification attached.

So the rule that resolves most of this: aggregate by default, individual never, with two documented exceptions. Write it down, because the defence of the position is much easier when it predates the request.

The Report That Should Not Exist

Some capabilities are hazards regardless of policy, because policy is a promise and a capability is a fact.

A keyword search across question logs with identifiers attached is the clearest example. It lets anybody with console access ask who has been reading about redundancy, who has asked about parental leave, who is looking at the grievance procedure. Every one of those is information about somebody's private circumstances that they disclosed to a help system, not to their employer's management.

The uncomfortable part is that the first legitimate-sounding use arrives quickly. Who asked about the new expenses rules, so we can follow up. Who has been asking about the benefits window, so we can remind them. Both are helpful in intent, and both normalise a query pattern that is indefensible one step later.

If your product can produce this report, you have three options in descending order of reliability.

Turn off identity collection entirely. The log holds questions and no identifiers. Aggregate reporting works perfectly. Individual history becomes impossible rather than discouraged, which is the only enforcement that survives staff turnover. The cost is that you cannot personalise answers and cannot follow up on a specific complaint, and for a first deployment that cost is usually worth paying.

Restrict console access to one or two named people and write down what they may query. Weaker, because it depends on those people and on their successors, but workable where identity is needed for other reasons.

Pseudonymise. Identifiers replaced with tokens, with the mapping held separately and accessible only through a documented process. This is the arrangement that scales, and it is more configuration than most mid-size deployments will do.

What does not work is a policy saying nobody will run the report, on a system where anybody can run the report.

What People Actually Worry About

Will my manager see what I asked?

This is the first question employees ask and it determines whether they use the system for anything that matters. If the answer is anything other than a plain no, they will use it for holiday balances and nothing else, and the deployment will look successful on volume while missing every question that was worth answering. Say no, and make it true.

Does asking about something flag me?

People genuinely believe this, and the belief is not paranoid: a system that logs questions with names attached could flag somebody, and employees have no way to verify that it does not. The only answer that works is to describe the arrangement specifically rather than reassure generally, because reassurance from the party holding the data is not evidence.

Is this being recorded for a performance review?

The fear underneath this is that asking questions looks like incompetence. It matters most for new starters, who have the most questions and the most to lose from appearing to need help. An explicit statement that question history plays no part in any assessment is worth including even though it sounds like it should go without saying.

What happens to the difficult thing I typed?

Somebody who types a disclosure into a chat box, then deletes it and rephrases, has usually not realised the first version was already sent. They should be told that it was, and told how long it is kept, because the alternative is discovering it later and concluding they were misled.

Can I see what you have about me?

A reasonable request, and the honest answer in most deployments today is that nobody has checked whether the product supports it. Find out before somebody asks, because a request of this kind arriving with no process behind it is handled badly and remembered.

What the Aggregate Report Should Contain

Everything above says aggregate reporting is the safe and useful half, and then does not say what to build. Here is the report, which is five numbers and one list.

Question volume, by week. The headline number, and the only one anybody asks for unprompted. Useful mainly as a denominator for the rest and as the thing that tells you whether a rollout announcement worked.

Topic distribution, by your own categories rather than the vendor's. Group questions by what people were trying to do: book leave, understand sick pay, change a detail, find out about benefits. Vendor-supplied topic clustering tends to group by vocabulary, which splits the same intent across three labels and merges two different ones. Twenty categories you defined beat a hundred the tool inferred.

Unanswered count and rate. The single most actionable figure in the whole deployment, because each one is a documentation gap that somebody has already needed. Track the rate rather than the count, or a quiet week looks like an improvement.

Repeat rate within a session. How often somebody asked substantially the same thing twice. This is the closest available proxy for the answer not landing, and it catches the failure that satisfaction scores miss entirely, because people do not rate an answer badly, they rephrase and try again.

Documents cited, ranked. Which sources are carrying the answers. The top five tell you where to spend review effort, and the long tail of documents never cited once in a quarter tells you what is in the corpus for no reason.

And one list: the unanswered questions themselves, in the asker's words, with no identifier. This is the single most valuable artefact the system produces and it carries no personal data at all once the identifier is stripped. It is also the one thing teams most often cannot get, because the export includes identity by default and nobody configured it otherwise.

Nothing on that list needs a name attached. That is the point worth making internally when somebody argues that useful reporting requires identity: here is the report, it is better than what they were asking for, and it is built entirely from fields with no personal sensitivity.

Five Questions to Settle Before Launch

Who holds the admin credential, and who is the second holder? One person holding sole access is not a security control, it is a single point of both failure and discretion. Two named people with a written scope is the minimum, and the scope matters more than the number.

What does the vendor's support team see? Most products allow vendor-side support staff to view conversations when investigating a ticket. That is reasonable and it means your access list has names on it that are not in your organisation. Ask, and get the answer in writing.

Is your question text used for training? Ask specifically whether your conversations are used to improve the vendor's models, whether that is on by default, and whether it can be turned off. The answer varies by product and by plan, and the default is not always the one you would choose.

Where is the data stored, and who are the sub-processors? Not as a compliance exercise for its own sake, but because the answer determines who else is in the chain. A product with three sub-processors has three more parties than the contract's front page suggests.

What happens to the logs when you stop paying? Deletion on termination is standard in good contracts and absent in many. Ask what the retention period after cancellation is, because a dataset of employee questions sitting with a vendor you no longer use is the worst version of this problem.

Retention, Where the Default Is Wrong

Most products retain conversation history indefinitely, because storage is cheap and deleting data is a feature nobody asks for during a sales process.

Work out what you actually need from the age of a log, and the answer is short.

The last thirty days supports everything operational: finding gaps, checking answer quality, reading the unhelpful flags, understanding what changed after a policy update. This is where essentially all the value is.

Ninety days covers a quarterly review cycle and lets you compare a month against the same month last quarter. This is a comfortable ceiling for full question text.

Beyond ninety days, keep counts and not content. How many questions on which topics, how many unanswered, which documents were cited. That is enough for a year-on-year view and it carries almost no personal information, which means it can be kept as long as it is useful without accumulating risk.

Indefinitely, with identifiers attached, is the default and is a liability that grows. Three years of question text tied to named individuals is a dataset nobody designed, nobody reviews, and somebody will eventually have to disclose, search or explain.

So set a retention period on day one. It is a single setting in most products, it takes a minute, and doing it later means deciding whether to delete history that somebody has by then found a use for.

Telling People, Which Is Not Optional

One paragraph, published before launch, in the announcement rather than in a policy document nobody opens.

It needs four things. What is stored, in plain terms: the questions and the answers. Whether a name is attached, answered yes or no rather than described. Who can see it, by role, and specifically whether managers can. How long it is kept, as a number of days.

And it needs one sentence on what the data is used for, which should be a short list rather than a general purpose: improving the answers and finding gaps in the documentation. Not improving HR services, which is broad enough to cover anything.

Write it in the second person and keep it under 120 words. A long privacy notice reads as a document written to protect the company. A short specific paragraph reads as an answer, and this is a case where the form carries as much signal as the content.

Then make the assistant itself able to answer the question. Somebody will ask the bot whether their questions are private, which is a question about the system asked to the system, and the answer should be the same paragraph rather than a decline. Put it in the corpus.

The Options

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, priced flat at $29, $69 and $199 a month with unlimited seats. Unlimited seats is relevant here for a reason that is not about money: a product that does not price per user has no commercial reason to insist on identifying users, which makes an anonymous deployment straightforward rather than a configuration fight.

Its cons stand unchanged: it has no free tier, it answers rather than actioning tickets, and it is not an HR or ITSM workflow platform. On this topic, verify the specifics yourself rather than taking the shape on trust: ask what the retention period is, whether it is adjustable, whether conversation logs can be exported, and who in your own organisation would hold the admin credential.

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.

Relevant here: it is a ticketing platform, so conversations become records inside a system built for audit and role-based access, which is a genuine advantage for controlling who sees what. The same property is the risk, because a ticket is designed to be visible to a team and a sensitive question becomes a record several people can read by default.

Zendesk

Suite Team at $55 per agent per month, Copilot at $50 per agent per month, so $105 per agent per month together. At twenty agents that is $2,100 a month.

Relevant here: mature role and permission controls, the most granular on this list, built for support organisations where who-can-see-what is a longstanding requirement. The defaults are tuned for customer support, where logging a customer's full history is normal and uncontroversial, and that default assumption is the thing to change for internal HR use.

Leena AI and Moveworks

Enterprise platforms built around knowing who the asker is. Neither publishes a price.

Relevant here: identity is a core assumption rather than a setting, because personalising answers is much of what they sell. That makes an anonymous deployment close to impossible and makes the access-control conversation part of the implementation, which is both more thorough and less in your hands.

Crisp

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

Relevant here: workspace pricing again removes the commercial pressure to identify everybody. It is a shared inbox at heart, which means conversations are visible to the team by design, and for HR that default needs examining rather than accepting.

SiteGPT

A document and site-trained answering 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.

Relevant here: built for public websites, so anonymous visitors are the normal case and identity is the exception, which happens to suit a privacy-first internal deployment well.

The Comparison

The first column is the one that makes the policy enforceable rather than aspirational.

The Decision Table

The Three Approaches, With Their Real Costs

Anonymous by default

No identifier stored. The log holds questions, answers and timestamps. Aggregate reporting works in full.

What it costs you. Answers cannot be tailored to a population, so a contractor and a permanent employee get the same reply and the scope has to be handled in the documents instead. You cannot investigate a specific complaint, so when somebody says the assistant told them something wrong yesterday the only honest response is to ask what they asked and reproduce it. And you lose the ability to see whether one person is struggling repeatedly, which sounds like a loss and is mostly the surveillance capability under a kinder description.

What it buys. A policy that holds without depending on anybody's restraint, including the restraint of people who have not been hired yet. This is the strongest argument for it and it is an argument about time rather than about privacy.

Pseudonymised

A stable token stands in for each person. The mapping between token and name is held separately, and reaching it is a documented process rather than a console query.

What it costs you. Real configuration work, a decision about who holds the mapping, and a process somebody has to write. It is also only as strong as the separation: a mapping stored in the same admin console is theatre.

What it buys. Nearly everything useful. You can see that one token asked six questions in a session without knowing whose session it was, which is the genuinely valuable signal. Personalisation by population works if the token carries a population label rather than an identity.

Fully identified

Names attached, as most products ship.

What it costs you. The capability this article is about, permanently, along with the obligation to control it by policy forever. Also the adoption cost, which is invisible and large: the questions that do not get asked never appear in any report.

What it buys. Personalised answers, follow-up on complaints, and routing a sensitive question to a named person. Those are real and they are worth having at some scale. They are not worth having by default, on day one, because the installer did not change a setting.

The Three Checks Worth Running This Week

Open the admin console and try to produce the forbidden report. Search the logs for a keyword and see whether names come back. This takes two minutes and it replaces an assumption with a fact. Several teams who were confident their deployment was anonymous have found identifiers attached because a single sign-on integration was added for convenience three weeks after launch.

Find the retention setting and read its current value. Not what the contract says. The value in the product. Then set it to ninety days or shorter.

List everybody who can read a conversation. Not everybody who should. Everybody who can, including whoever administers the identity provider, whoever has access to the vendor's support tooling, and anybody holding a shared credential. The list is usually longer than the one in anybody's head, and the gap between the two is the whole finding.

A fourth check, if the first three come back clean. Ask the assistant itself what it stores about you. Type the question an employee would type, in the words they would use, and read what comes back. If it declines, or improvises something reassuring that nobody wrote, that is the answer thousands of people will get to the question that decides whether they trust the thing. It costs one paragraph in the corpus to fix and it is the last item on every launch checklist that includes it at all.

Consultation, Where It Applies, and Why Doing It Anyway Helps

Whether you are required to consult anybody before deploying this depends on where you operate, what representative arrangements exist, and what your own agreements say. That differs by jurisdiction and by circumstance, so take local advice rather than a general answer from an article. What follows is the practical argument, which holds regardless of what is required.

Consulting is cheap here and it buys something specific. A works council, a staff forum, a union representative or simply a group of employees asked in advance will raise exactly three concerns: can managers see this, does asking count against me, and how long is it kept. Those are the three questions this entire article is about, and they are answerable in a sentence each if you have done the work.

So the consultation is not a hurdle, it is a free design review by the only people whose adoption decides whether the deployment works. Teams that have run it describe the same pattern: the questions are predictable, answering them takes twenty minutes, and the representatives then become the channel through which the reassurance reaches everybody, which is far more effective than an announcement from HR about HR's own tool.

What to bring to that conversation. The paragraph you intend to publish, the retention number, the access list including the vendor, and the aggregate report template so people can see what is actually being measured. Bringing the report template is the move that changes the tone of the meeting, because it replaces speculation about surveillance with a concrete artefact that visibly contains no names.

What not to do. Do not present it as a consultation if the decision is made and unchangeable, because that is worse than not consulting. And do not promise a control you have not configured, since the first thing a sceptical representative will ask in six months is whether the promise is still true.

What Getting This Wrong Costs

The direct cost is a system people use only for trivia. That is the common outcome and it is quiet: volume looks fine, the questions are all about holiday balances, and the gap log contains nothing difficult because nobody risked typing anything difficult. The deployment is reported as a success and it answers none of the questions that were expensive.

The sharper cost is the one incident. A manager produces a list of who asked about redundancy, or an employee discovers their session history was read, and trust in the whole arrangement goes at once. It does not recover, and it tends to take the next internal tool with it, because the lesson people learn is about the employer rather than about the product.

And there is the cost of having the capability at all. A dataset of named employees' private questions, retained indefinitely, is something you will eventually have to disclose, search, explain or defend. Nobody chose to build it. It accumulated from a default setting and an admin credential, which is precisely why the three checks above are worth more than any amount of policy writing.

The Deleted Message, and Other Things People Do Not Expect

Three behaviours that surprise employees when they find out, each of which is worth stating in the paragraph rather than leaving to be discovered.

A message is sent the moment it is sent. People compose a difficult question, send it, then immediately send a second message walking it back or rephrasing. Both are in the log. In a chat interface that looks conversational and ephemeral, this is genuinely counterintuitive, and somebody who assumed otherwise has a reasonable grievance when they learn the truth later rather than earlier.

The conversation is one object, not a series of questions. Somebody asking about sick pay, then notice periods, then references, has not asked three unrelated questions. The session reads as a narrative to anybody who looks at it, and that narrative is more revealing than any one question. Employees generally have not thought about this, and it is the strongest practical argument for either anonymity or pseudonymisation, because the session is the unit where the real disclosure happens.

A question asked at an unusual hour carries the timestamp. Nobody intends to disclose that they were researching compassionate leave at two in the morning. The timestamp is operationally useful in aggregate and it is personal in combination with the text, which is why the retention period matters more than it looks: ninety days of question text with timestamps attached is a much smaller thing to hold than three years of it.

So the paragraph you publish should say that whole conversations are stored rather than individual questions. It is one extra clause and it closes the gap between what people assume and what is true, which is where almost all trust damage in this area comes from.

When You're Ready to Add Identity

There are real reasons to identify askers eventually, and the honest sequence is anonymous first, identity when a specific need justifies it.

The needs that justify it: answers that depend on which population somebody belongs to, following up on a specific complaint about a wrong answer, or routing a sensitive question to the right person by name. Each is concrete and each should be written down as the reason before the setting changes.

What to put in place at the same time. The retention period, shortened rather than inherited. Pseudonymisation, so the identifier in the log is not the person's name. A written rule on aggregate versus individual access with the two exceptions named. A second named admin, so access is a decision rather than an accident of who installed it. And an updated paragraph for employees, published when the change happens rather than discovered afterwards.

So the order is the point. Identity is easy to add and nearly impossible to remove, because once answers depend on it, taking it away degrades the product. Starting without it costs you some personalisation and buys you a policy you can actually keep.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements.