Should the Bot Answer a Manager Differently From an Employee?

TL;DR

• The reason to separate audiences is usually relevance rather than secrecy. An employee receiving the manager's script for a difficult conversation has had a bad answer, not a leak.
• Three populations need thinking about: employees, managers, and anybody engaged through a contract or an agency.
• An anonymous widget cannot separate audiences at all, because it does not know who is asking. That single fact decides the architecture.
• Three arrangements exist. One corpus for everybody, one assistant per audience, or one assistant filtering sources by who is asking. Ask which your product does before you design around it.
• Start with the everybody corpus. It is the only one that needs no identity, and most companies never need more.
• Test by asking the same five questions as each audience in turn. The answers should differ in scope, not in accuracy.

The Employee Who Got the Manager's Script

A company put its people documents into an HR chatbot and included the manager guidance, because it was good material and well written.

Within a fortnight somebody asked how to raise a concern about their manager. The answer they received was accurate, sourced, and taken from the document written for managers on handling a concern raised about a colleague. It described how to assess the complaint, what to record, and when to escalate.

Nothing confidential had been disclosed and the answer was still wrong, because it was written for the person on the other side of the conversation. The employee had asked what to do and been handed the procedure for processing them. They mentioned it to two colleagues, and the story that circulated was not about a leak. It was that the bot treated them like a case.

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

That is the actual shape of this problem. Access control in an employee assistant is mostly not about secrecy, and framing it as a security question produces the wrong design.

Relevance, Not Secrecy

Three categories of document, and only one of them is about confidentiality.

Written for everybody. The handbook, the benefits summary, the leave policy. No separation needed, and the great majority of what an assistant should answer from sits here.

Written for a specific role. Manager guidance, approval procedures, the pay review process from the reviewer's side. Not secret in most companies, frequently published on an intranet, and the wrong answer to give somebody in the other role. This is the category that causes the incident in the opening example.

Genuinely restricted. Compensation data, case files, anything about a named individual. These should usually not be in an employee-facing corpus at all, which is a curation decision rather than an access decision.

So the design question is not what to lock. It is which audience each document was written for, which is something its author can answer in one word, and which you are probably not recording anywhere today.

The Identity Constraint That Decides Everything

Before any of the architecture matters, one question: does the assistant know who is asking?

If it is an anonymous widget, it cannot separate audiences. There is no identity, so there is no basis on which to answer differently. Everything it can read, it will answer to anybody who opens it. That is not a configuration gap, it is the nature of an unauthenticated surface, and no amount of product capability changes it.

If it sits behind single sign-on, you have an identity and therefore an option. Whether the product uses it is a separate question and one to ask directly.

And if it is in a chat tool where people are already signed in, you usually have identity for free, which is the most common practical route into this.

This matters more than it sounds because of the order companies do things in. The widget is the easiest thing to deploy, so it tends to go first, and then somebody asks for manager content to be added. At that point the honest answer is that it cannot be added safely to that surface, and the work is to stand up an authenticated one rather than to adjust a setting.

Because the identity decision is made implicitly by whoever chooses the deployment surface, it is usually made before anybody has thought about audiences at all. Ask the question in week one.

The Three Arrangements

One corpus, everybody

Everything the assistant can read is material anybody may read. Role-specific documents stay out.

Right for a first deployment, for any anonymous surface, and for the majority of companies indefinitely. It needs no identity, no per-audience configuration, and it cannot produce the opening example because the manager guidance is not in scope.

Where it struggles: managers then have no assistant for the questions they actually have, which is a real loss rather than a theoretical one, and it tends to produce a request to add the manager material within a month.

One assistant per audience

Two or three assistants, each with its own corpus, each on a surface the right people reach. An employee assistant on the intranet, a manager assistant in the manager space.

Right when you have genuinely different populations and a product that makes standing up a second instance cheap. Conceptually clean, easy to explain, and easy to audit, because what each one can read is a list rather than a rule.

Where it struggles: duplicated maintenance. The handbook now sits in two corpora and must be updated in both, and that divergence is the failure mode. Keep shared documents in one place and reference them rather than copying.

One assistant, sources filtered by who is asking

A single assistant that consults a different subset of sources depending on the identity of the person asking.

Right when the product supports it properly, which is the thing to verify rather than assume. It avoids the duplication and keeps one surface.

Where it struggles: it is the hardest to verify and the easiest to misconfigure, because nothing visibly changes when a filter is wrong. The only way to know it works is to ask as each audience, which is why the test section below matters most for this arrangement.

When You Should Not Separate Anything

When everything is published anyway

If your manager guidance is on the intranet and any employee can read it today, separating it in the assistant is theatre. It may still be worth doing for relevance, and it is not a security measure, and saying so keeps the conversation honest.

When there is one population

A company where essentially everybody does similar work and the manager layer is three people does not need an architecture. It needs the everybody corpus and one person who answers the three managers directly.

When the surface is anonymous

Covered above and worth repeating as a decision rather than a constraint. On an anonymous widget the correct answer is to restrict the corpus, not to attempt separation.

The edge case that forces it

Contractors, or a population whose employment arrangement differs. The moment somebody is asking about benefits they do not have, you have an audience problem that relevance alone will not solve, and the next section is about that.

The Third Population Nobody Designs For

Managers and employees get thought about. People engaged through a contract or an agency almost never do, and they produce a distinct failure.

The issue is not confidentiality. It is that most of your corpus does not apply to them. They ask about annual leave entitlement, parental provisions or a benefits scheme, receive a confident and accurate answer from the employee handbook, and act on something that was never written about their arrangement.

That is worse than no answer, because a refusal sends them to a person while a confident wrong answer does not. And it is a particularly awkward failure to discover, since the person has been told something about their own circumstances by a system the company put in front of them.

Three ways to handle it, in order of preference.

Keep them on a corpus written for them. Usually small: how to get access, who to contact, how to submit time, the practical arrangements. Honest and genuinely useful.

Or give the shared assistant an explicit scope statement. A line in the answer or the interface saying it answers from employee policy documents, so somebody on a different arrangement knows to ask a person. Cheap, imperfect, and much better than nothing.

Or keep them off it entirely, which is defensible and should be a decision rather than an oversight.

How any particular arrangement is characterised, and what applies to whom, differs by jurisdiction and by circumstance, so take local advice on that rather than inferring it from how your documents are organised.

What Managers Actually Need

Worth stating, because the usual objection to separating audiences is that it deprives managers, and the fix is to give them something rather than to merge everything.

Four question types, none of which an employee corpus answers well.

Procedure from the other side. How to receive a request, what to record, what the timescales are, when to involve somebody else.

The judgement questions. Whether something is a conversation or a process, which is the question managers most want answered and the one most likely to need a human.

Their own obligations as a manager. Approvals they own, deadlines they are responsible for, what they must not promise.

And the awkward ones they will not ask a person. Whether they can decline a request, how to handle a performance concern that might be something else. This is where a manager assistant earns its place, because the alternative is that the question does not get asked at all.

So a manager assistant is not the employee one with more documents. It is a different corpus answering different questions, and treating it as an expansion of scope is what produces the opening example.

Testing It, Which Is the Only Verification

The configuration will look correct whether or not it is. Five questions, asked as each audience in turn, written down.

A question only the employee corpus answers. Leave entitlement, say. Every audience should get this, correctly.

A question only the manager corpus answers. How to handle a request. The employee account should get a refusal or a redirect, not the procedure.

A question that exists in both with different answers. Something like how a pay review works, which reads differently from each side. Both should be correct for their asker.

A question about something a contractor does not have. From a contractor account if you have one, or from the arrangement you have set up for them. You are checking it does not confidently quote the employee handbook.

A question with no answer anywhere. Confirming the refusal behaviour still works per audience, since a mis-set filter sometimes produces a confident answer from the wrong corpus rather than a refusal.

Do this before launch and again after any corpus change. And ask somebody who is actually a manager to do the manager half, because you will unconsciously phrase the questions in a way that works.

The Options

Matram

Disclosure: Matram is owned by the same people who publish HROpsLab. It answers from the sources you give it, with strict mode so it will not answer from outside them, a human handoff for the questions it should not take, and 95 or more languages. Pricing is flat per month with unlimited seats: $29, $69 and $199, which matters for this subject because a per-seat product makes a second audience a second bill.

Its limits: there is no free tier, it answers questions rather than actioning tickets, and it is not an HR or ITSM workflow platform. For audience separation specifically, the thing to establish with any product including this one is whether separation is by separate instance or by source filtering on identity, and to test it rather than take the answer.

Leena AI and Moveworks

Both built for enterprise employee support, where multiple populations and identity-aware answering are core assumptions rather than additions.

Both publish no price at all, so comparing them means a sales process before you have a number. For a company whose real requirement is two audiences and 40 documents, that evaluation is disproportionate.

Freshservice

Best where the assistant sits inside a service management platform that already knows who everybody is, which is a genuine advantage for this subject.

Read on 5 October 2026: $19, $49 and $99 per agent per month, with the Freddy AI add-on at $29 per agent per month. It publishes no language count.

Where it struggles: per-agent pricing, which prices the answerers rather than the askers.

Crisp

Best for a conversation-led deployment where the same tool serves customers and staff.

Read on 5 October 2026: $45, $95 and $295 per month, priced per workspace rather than per seat. It publishes no language count.

Where it struggles: audience separation in a tool built around inbound conversations is less natural than in a purpose-built internal assistant.

SiteGPT

Best for a document-trained assistant on a published surface, which is frequently an anonymous one and therefore the arrangement where separation is unavailable.

Read on 5 October 2026: Starter at $468 per year and Growth at $948 per year, both billed yearly, or $59 and $129 monthly. Never quote the lower monthly equivalents without saying they require annual billing.

Where it struggles for this subject: a public surface is the case where the corpus has to carry the control, since identity does not exist.

The Comparison

The last column is the one to price before you design, because an architecture that needs two assistants on a per-seat product costs differently from the same architecture on a flat one.

The Decision Table

Marking the Audience on Every Document

Everything above depends on one field that almost nobody records, so it is worth saying exactly what it is and how to populate it for an existing corpus.

One word per document: everybody, manager, or restricted. Not a classification scheme, not a sensitivity level. Who was this written for.

Get it from the author, not from a reviewer. Whoever wrote the leave policy knows in a second who it was for. Somebody reading it a year later has to infer, and will sometimes infer wrongly in the direction of caution, which is how a useful document ends up out of scope.

Do it as a single pass over the list. For a corpus of 40 documents this is about 20 minutes with the list open and the authors available on chat. It is not a project and it does not need a meeting.

Default to everybody and mark the exceptions. Most of a people corpus genuinely is written for everybody, so the efficient question is which ones are not. Asking the inverse produces a long argument about the whole estate.

Record it next to the owner, in the same list. Two columns, one line per document. That list is now the specification for whichever of the three arrangements you choose, and it is the artefact that makes the choice obvious rather than theoretical.

Then add a third column for the date it was marked, because an audience can change. A document written for managers that gets published to everybody has moved category, and nothing in the assistant will notice.

Keeping One Handbook Across Two Corpora

Because the per-audience arrangement duplicates the shared documents, the thing that will go wrong is divergence, and it will go wrong quietly. Two copies of a leave policy, one updated in March and one not, both answering confidently.

Four habits prevent it, and none needs a tool.

Keep one authoritative copy and point both corpora at it. Most products take a source by reference rather than by upload. Where yours does, this is the whole fix: the file lives once, two assistants read it, and an update propagates to both because there is only one.

Where you must upload, record which corpora hold each document. A column in the document list. Then an update is a two-line task rather than a thing somebody remembers unevenly.

Date the answer, not just the document. Several products will tell you when a source was last indexed. Checking that figure across both corpora after an update takes a minute and catches the case where one re-indexed and the other did not.

And test the same question in both after any change to a shared document. One question, two surfaces. If the answers differ, you have found the divergence while it is still an hour old rather than after somebody acted on the stale one.

So the maintenance overhead of the two-assistant arrangement is real and it is a list and a habit rather than a project. The companies that find it unmanageable are the ones that uploaded everything twice and kept no record of what went where.

Moving From an Anonymous Widget to an Authenticated One

So if you started with a widget and now need audiences, this is the piece of work, and it is worth knowing it is a deployment change rather than a configuration one.

Decide the surface first. The three realistic options are an intranet page behind your existing sign-in, your chat tool where people are already authenticated, or a dedicated portal. The chat tool is usually the cheapest and gets the highest usage, because it is where people already are.

Expect the question volume to change, not just the audience. An authenticated surface inside a chat tool gets asked far more, and more casually, than a widget somebody has to find. Budget for that in whatever your product prices on.

Keep the widget if it was serving a purpose. An anonymous assistant answering published policy questions is still useful, and the two can coexist: a restricted public one and a fuller authenticated one. What must not happen is the fuller corpus reaching the anonymous surface, so if you run both, the corpus separation is now load-bearing and belongs in the quarterly review.

Then re-run the five audience questions on the new surface, because the identity plumbing is new and the only way to know it is wired correctly is to ask as two different people and compare.

And tell people the surface moved. A tool that was on the intranet and is now in chat loses its existing users silently, which reads as the assistant having been withdrawn.

Building the Manager Corpus, in Order

The manager assistant is a different product from the employee one, so it is worth building in the order that gets it used rather than the order the documents happen to exist in.

Start with the four question types, not the documents. Ask three managers what they last had to look up and could not find. The answers cluster quickly, and they are almost never the documents somebody would have picked.

Write the procedure-from-the-other-side documents first. Receiving a request, what to record, the timescales, when to involve somebody else. This is the highest-volume category and usually the thinnest in existing material, because it lives in people's heads.

Then the obligations list. What a manager owns, what they must not promise, which approvals are theirs. One page, and it prevents a specific category of expensive mistake.

Leave the judgement questions to a human and say so. Whether something is a conversation or a formal process is the question managers most want answered and the one an assistant should decline. Build the handoff properly instead, so the refusal arrives with a named person rather than as a dead end.

And include the employee-facing documents too. Managers need to know what their people were told, and a manager assistant that cannot answer an ordinary leave question is one they will stop opening. This is the single most common reason a manager assistant gets abandoned in its first month: it was built as an addition to the employee corpus rather than a superset of it, so it could answer the rare question and not the frequent one.

Check it against what managers actually asked, after a quarter. The unanswered-question queue from the manager assistant is a better specification than anything written in advance, because it records real questions rather than anticipated ones. Three managers guessing in week one gets you started; 90 days of real questions tells you what to write next.

That last point is why the manager corpus is a superset rather than a separate set, and it is also why the relevance problem only runs one way: a manager seeing employee guidance is fine, while the reverse is not.

Who Approves a New Document

And within about a month of launch somebody will ask for their department's documents to be added, reasonably, which is the moment a curated corpus becomes a folder again unless one person owns the answer.

Name the approver before launch. One person, not a committee, and preferably whoever owns the handbook rather than whoever owns the platform. The question being asked is editorial, not technical.

Give them three questions to apply. Who was this written for, who owns it, and does it contradict anything already in the corpus. The third is the one that matters most and the one nobody asks: two documents giving different answers to the same question is worse than one document giving none.

Set an expectation on turnaround. Five working days. An approval route with no stated time becomes a route people go around by asking an administrator directly, and once that happens twice it is the real process regardless of what the document says.

Log every addition with its date and approver. One line. After two quarters that log tells you whether the corpus is growing deliberately or by accretion, which is the difference between the curated list and the folder you replaced.

And say no sometimes, visibly. A route that has never refused anything is not an approval process, and the first refusal is what establishes that the corpus has a shape. The usual good refusal is a document written for a single team that would answer a question wrongly for everybody else. A team's own onboarding notes are the classic case: genuinely useful to twelve people and actively misleading to the other three hundred, because they describe one team's conventions as though they were company policy.

What Getting This Wrong Costs

The visible cost is the awkward answer, and it is usually handled with an apology and a document change.

The second cost is the one that lands on managers. When separation is impossible or unbuilt, the practical response is to restrict the corpus to what everybody may read, and the people who lose are managers, who then have an assistant that cannot answer any of the four question types they actually have. Because they will not complain about a tool that was not built for them, this gap stays invisible, and the company concludes the assistant has limited value when what it has is a missing audience.

The third is trust, and it runs in a direction people do not anticipate. An employee who receives the manager's procedure for processing a concern does not conclude that the configuration is wrong. They conclude something about how the company sees them, and that conclusion travels. One answer like that is worth more damage than a month of correct ones is worth goodwill.

The reframing question: if an employee and their manager asked your assistant the same question about raising a concern, would both answers be right for the person who asked?

When You're Ready to Add a Second Audience

The honest position is that the everybody corpus is the right starting point and most companies should stay there longer than they expect. It needs no identity, it cannot produce the relevance failure, and it covers the questions that generate the volume.

The trigger worth acting on is a specific request with a specific document behind it. Not a general sense that managers should have more. Somebody asking for the manager guidance to be added, naming it, because they were asked a question they could not answer.

The sequence costs an afternoon. Establish whether your surface knows who is asking, because that answer either opens or closes the whole option. Ask the vendor whether separation is by instance or by source filtering, in writing. Mark each document in your corpus with the audience it was written for, which its author can do in one word. Then decide which of the three arrangements you are building and write down which documents each audience sees.

And run the five questions as each audience before you let anybody in. Of everything here, that test is the only thing that distinguishes a working separation from a configuration that merely looks correct.

One thing worth resisting, because it arrives as a sensible-sounding suggestion in the first design conversation. Somebody will propose mirroring your existing document permissions into the assistant automatically, so that each person's answers are drawn from whatever files they can already open. It sounds like the correct answer and it is a poor one in practice for two reasons.

The first is that document permissions in most companies are an accident of history rather than a design. Folders inherit from folders, people inherit from teams they left, and the result is a permission map nobody has audited. Projecting that into an assistant produces answers that differ between two colleagues in the same role for reasons neither can see, which is harder to explain than a deliberate rule and much harder to debug.

The second is that it answers the secrecy question and not the relevance one. Permissions tell you who may read the manager procedure. They say nothing about whether an employee who may read it should be handed it in response to a question about raising a concern. The failure in the opening example would have happened anyway, because that document was readable by everyone.

So three audiences, marked by hand, with the mapping written down, beats an automatic mirror of a permission structure nobody designed. It is also considerably easier to test, which over three years is the property that matters most.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the owner's own product is named above with its three limitations rather than its three best features.