TL;DR
- Retrieval quality is mostly a document problem, not a model problem. The same assistant over a restructured handbook answers questions it previously declined.
- The unit that matters is the paragraph, because that is roughly what gets retrieved and returned. A nine-sentence paragraph holding four separate facts cannot be an answer to any of them.
- Four formatting habits break retrieval reliably: facts locked in PDFs and images, conditions nested inside prose, pronouns that point back across a heading, and context stated once in an introduction that nobody retrieves.
- Headings should read like the questions people actually ask. A section called Absence Management answers nothing; one called How much notice do I give for annual leave answers itself.
- Do not rewrite the handbook. Fix the twenty documents that answer eighty per cent of real questions, which you can identify from one month of inbound.
- Every statement needs a date and an owner. Without those, nobody can tell a current answer from a stale one, including the assistant.
The Handbook That Answered Nothing
A 260-person company pointed an answering agent at its full document set: a 94-page handbook, eleven standalone policies, and the intranet. Six weeks later the assistant was declining roughly a third of questions and getting a further portion subtly wrong, and the internal conclusion was that the product was weak.
The product was fine. One example settles it. Somebody asked how much notice they needed to give to book a week off. The handbook contained the answer, inside a paragraph that began by describing the company's general philosophy on flexibility, went on to mention that different teams had different operational constraints, noted that managers had discretion, and in its seventh sentence said that two weeks was the normal expectation for absences of three days or more. The retrieval found that paragraph. It returned a passage about flexibility and discretion, which is what most of the paragraph was about.
The fact was there. It was not findable as a fact, because it had been written as a clause inside an argument. A human skimming the page would have found it in about fifteen seconds, because a human can scan for numbers and ignore the surrounding sentiment. Retrieval cannot. It matches on meaning across a block of text, and the meaning of that block was flexibility.
Best tools for AI HR Tools
So the fix was not a better model. It was taking one paragraph and turning it into a heading, a one-line answer and a short note about exceptions. That took four minutes. The assistant answered the question correctly from then on, and twenty-two other questions turned out to have the same shape.
Why the Paragraph Is the Unit That Matters
You do not need to understand embeddings to write documents that work. You do need one mechanical fact about how these systems read.
An HR chatbot does not read your handbook the way you read a book. It splits every document into passages, usually something close to a paragraph or a short run of paragraphs, and stores each one separately. When a question arrives it finds the passages whose meaning is closest to the question, and composes an answer from those passages alone. Nothing outside the retrieved passages is available to it in that moment.
Three consequences follow, and all of the practical advice in this article comes out of them.
A passage has to stand on its own. If understanding it requires the sentence before it or the heading three levels up, the assistant gets a fragment it cannot interpret. People write with the whole document in mind. Retrieval has only the fragment.
A passage about several things is close to nothing. Meaning gets averaged. A paragraph covering notice periods, manager discretion and company philosophy sits somewhere between those three topics, and it is therefore a weak match for a precise question about any one of them. Splitting it into three short paragraphs produces three strong matches.
Format is content. A fact inside a scanned image is not in the document as far as retrieval is concerned. A fact inside a table may survive or may arrive as a row of disconnected cells, depending on how the table was produced. If it was never extractable as text, it does not exist.
| What you wrote | What retrieval gets | What the employee sees |
|---|---|---|
| One paragraph, four facts | A passage about four things, weakly | A vague answer touching all four |
| One paragraph, one fact | A precise match | The fact |
| A fact in a scanned PDF table | Nothing | A decline, or a guess from elsewhere |
| A condition nested in prose | The prose, condition included but buried | The general case, exception dropped |
| It in place of the policy name | A passage whose subject is unclear | An answer about the wrong policy |
The Four Habits That Break Retrieval
Habit one: facts that are not text
This is the largest single cause and the easiest to fix. Pay bands in a screenshot of a spreadsheet. The benefits summary as a designed PDF where the numbers are part of the artwork. The org chart as an image. A policy that exists only as a slide deck from a town hall.
None of that is readable. Some products run optical character recognition and recover part of it, which is worse than failing, because you cannot tell which parts came through and which did not. A number that recovers as 12 instead of 1.2 is a confident wrong answer with no visible cause.
The fix is to keep the designed version for people and maintain a plain text or HTML version for the machine. Not a summary. The same facts, as text, in one place, updated at the same time as the designed one. Teams that try to maintain two versions by discipline alone end up with divergence inside a quarter, so make the text version the source and generate the pretty one from it where you can.
Habit two: conditions nested inside sentences
HR writing is full of legitimate conditionality, and the way it usually gets expressed is the problem rather than the conditionality itself.
Consider a sentence saying that employees who have completed probation may request flexible working, subject to business need and manager approval, except in the first three months of a new role or where a prior request has been made in the preceding twelve months. Every clause there matters. As one sentence it is a single averaged passage, and a question about any one clause returns the whole thing, from which the assistant will usually surface the general permission and drop the exclusion.
Rewrite it as a short statement of the general rule, then each condition on its own line as a visible list. The content is identical. The retrievability is not, because each condition is now its own passage with its own meaning, and a question about the twelve-month rule matches the line about the twelve-month rule.
Habit three: pronouns and implied subjects
Documents written as continuous prose use pronouns constantly, and pronouns do not survive being split into passages.
A section headed Parental Leave that then says "it must be requested at least fifteen weeks before the expected week of childbirth" reads perfectly to a person, because the heading is right there. Retrieved on its own, that passage is about an unnamed it. It will match weakly against a question naming parental leave, and it may match something else entirely.
Name the subject in the sentence, not only in the heading. It reads slightly more repetitive to a human and it is the single cheapest improvement available. The same applies to "the above", "as described previously", "this process" and "the policy" when the policy is only identified in a heading two levels up.
Habit four: context stated once, at the top
Handbooks often open with a page explaining scope: that this document applies to permanent UK employees, that contractors are covered separately, that anything here is subject to the contract of employment. Then two hundred paragraphs follow, none of which repeats any of that.
Every one of those paragraphs is retrievable without the scope page. So an agency worker asks about sick pay, matches a paragraph written for permanent employees, and gets a confident answer about an arrangement that does not apply to them. The scope existed. It was just not attached to anything that gets retrieved.
The fix is a short qualifying phrase on each section rather than once per document, which feels redundant while writing and is the thing that stops the worst category of wrong answer. One clause is enough: a note that this section covers permanent employees and that contractors should see a different document.
What People Actually Ask, and What That Means for Headings
Go and read a month of real questions before touching a document. The vocabulary gap between how policies are titled and how people ask is wider than anybody expects.
Nobody asks about absence management. They ask whether they can take a day off tomorrow, whether a dentist appointment counts as sick leave, what happens if they run out of days, and whether their manager can say no. Nobody asks about remuneration frameworks. They ask when payday is when the first falls on a weekend.
Write headings as questions where you honestly can. A heading is a strong retrieval signal because it describes the passage beneath it, and a heading phrased as the question gives the system an almost exact match. There is a limit: a document of sixty question headings reads oddly and is hard for a person to scan. The workable compromise is a conventional section heading with question-shaped subheadings beneath it.
Use the words people use, at least once. If the policy is called Flexible Working Arrangements and everybody says working from home, put both phrases in the text. This is not keyword stuffing, it is the same reason a glossary exists. One sentence naming the informal term is enough.
Answer in the first sentence under the heading. Put the answer first and the context after. Most people stop reading at the answer, and retrieval returns the top of the passage more reliably than the bottom.
The Twenty Documents That Matter
The instinct on reading all of this is to rewrite the handbook. Do not. It is three months of work, most of it on documents nobody asks about, and it will not finish.
The distribution of real questions is steep. In every count worth looking at, a short list of topics accounts for the large majority of inbound: leave and how to book it, sickness and pay during it, pay dates and payslip questions, expenses, probation, notice, flexible working, parental leave, benefits enrolment, and how to change a personal detail. Everything else is a long tail of individually rare questions.
So the work is a morning of counting and then a focused fortnight.
Count first. One month of HR inbound, grouped by what was actually being asked rather than by which policy it touched. Twenty groups is usually enough to cover most of the volume, and the ranking almost always contains two surprises.
Fix the top twenty, properly. For each one: find the paragraph that holds the answer, give it a heading in the asker's words, put the answer in the first sentence, split the conditions onto their own lines, name the subject rather than using a pronoun, add the scope clause, and add a date.
Leave the rest alone until it asks to be fixed. The unanswered-question log tells you what the next ten documents are, with evidence, rather than guessing. Rewriting a document nobody queries is the most common way this work stalls.
One Policy, Before and After
The advice above is abstract until you have done it once. Here is the whole operation on a single policy, which takes about ten minutes and is the template for the other nineteen.
Before. A section headed Annual Leave, containing one paragraph of six sentences. It opens by saying the company believes rest is part of good work. It states the entitlement as 25 days plus statutory holidays, pro rata for part-time staff. It notes that the leave year runs from January. It says requests should be made with reasonable notice and are subject to manager approval and team cover. It mentions that up to five days may be carried over with agreement. It ends by saying anything unusual should be discussed with HR.
That is six facts in one passage. Ask it how many days you get and you may get the entitlement with the philosophy attached. Ask about carry-over and you get a passage mostly about something else. Ask what reasonable notice means and you get the sentence containing the phrase, which does not define it.
After. The same six facts, reorganised. A heading reading How much annual leave do I get, with the first sentence giving 25 days plus statutory holidays and a second line stating the part-time position explicitly rather than as the words pro rata. A heading reading When does the leave year start, answered in one line. A heading reading How much notice do I need to give, answered with the actual expectation as a number, because reasonable notice is not an answer and somebody in the business knows what it means in practice. A heading reading Can I carry days over, answered with the five-day limit and the condition on its own line. A line stating who the section covers. A last-reviewed date and an owner.
Nothing was added and nothing was cut. The same policy now answers four questions precisely instead of one question vaguely, and a person scanning the page finds what they came for faster too. The philosophy sentence survives, moved to the top of the section where it belongs, outside the passages that carry facts.
The only judgement call in that exercise was turning reasonable notice into a number. That is the general shape of this work: most of it is mechanical, and the small part that is not reveals a policy that was never actually decided.
The Questions Where the Answer Genuinely Is It Depends
Some rules really do vary, and pretending otherwise produces a document that is clean and wrong. Manager discretion is real. So is the difference between jurisdictions, between contract types, and between what a policy says and what a contract says.
The failure mode here is a document that hedges everywhere. If every statement carries three qualifications, every passage averages into a vague cloud, and the assistant returns hedging rather than information. Employees read that as the system knowing nothing, which is roughly correct.
The alternative is to state the common case plainly and put the variation next to it rather than inside it.
Name the default as a fact. If the normal expectation is two weeks notice and a manager may agree to less, the document should say two weeks as a plain statement, then say separately that a manager may agree to less. Two passages, two precise answers. A reader asking about notice gets two weeks, which is true for almost everybody, and an answer about discretion if they ask about discretion.
Put the decision rights in their own passage. Who decides, on what grounds, and what happens if they say no. That is a separate question and people ask it separately. Burying it inside the rule it modifies means neither question answers well.
Where the honest answer is that it varies by country or contract, say which document governs. Not a hedge. A pointer: this section covers the UK arrangement, staff employed through other arrangements should see the country annexe, and the contract takes precedence over this document where they differ. That is a useful answer. An assistant can return it, and it is better than a confident answer about the wrong jurisdiction.
Where nobody has decided, do not write around it. The gap log will surface these, and the recurring discovery is that the policy itself was never settled rather than being badly documented. Writing a vague paragraph to cover an undecided rule hides a decision somebody needs to make, and it is the one place where better documentation makes the underlying problem harder to see.
Dates, Owners and the Thing Nobody Adds
Two lines at the top of every document, and they do more for answer quality than anything else on this page.
Last reviewed, as a date. Not the file modification timestamp, which changes when somebody fixes a typo. A date somebody wrote down when they last checked that the content was still true. An assistant can be configured to say that a policy was last reviewed eighteen months ago, and that sentence does more for trust than any amount of hedging.
An owner, by name or role. When an answer is wrong, somebody has to be able to fix it. A document with no owner does not get fixed; it gets complained about. The owner line is also what makes the unanswered-question log actionable, because each gap can be assigned rather than discussed.
A version note where the policy has changed. This is the one people skip and it matters more than it looks. When a policy changes, the old version is still true for some period and for some people. A document that silently replaces its own content leaves the assistant unable to answer the most common question after any change, which is whether the new rule applies to a request already submitted. One line stating what changed and from when prevents an entire class of wrong answer.
The Formats That Work, in Order
HTML or markdown pages, one topic each. Best case. Clean headings, extractable text, easy to update, no layout to recover. A wiki or intranet page per topic is close to ideal.
Plain structured documents. A word processor file with real headings rather than bold text used as headings. The heading structure is what the splitter uses to decide where passages begin, so headings applied as formatting styles are doing real work and bold text is not.
Generated PDFs. Usable. The text is extractable, though multi-column layouts and headers and footers interleave into the text stream and produce noise. Acceptable for documents that have to exist as PDFs for other reasons.
Tables. Depends entirely on how they were made. An HTML table is usually fine. A table in a PDF often arrives as cells in reading order with no column association, which turns a pay band table into a list of numbers. Test any table that carries numbers you care about, and if it fails, write the content out as a short list as well.
Spreadsheets. Poor. The meaning lives in the position of a cell relative to a header row several rows up, and that relationship rarely survives. Export the content you need as text.
Scans, images and slide decks. Unusable, and dangerous when partially recovered. Re-key the content.
| Format | Retrieval quality | What to do |
|---|---|---|
| HTML or wiki page per topic | Strong | Preferred, no action |
| Document with real heading styles | Strong | Check headings are styles, not bold |
| Generated PDF | Adequate | Accept noise from headers and footers |
| HTML table | Usually fine | Test if it carries numbers |
| PDF table | Unreliable | Duplicate as a text list |
| Spreadsheet | Poor | Export the needed rows as text |
| Scan, image or slide deck | None, or worse | Re-key as text |
Testing Whether Any of This Worked
Rewriting documents without testing is how teams spend a fortnight and cannot tell whether it helped.
Build the test set before you edit anything. Take thirty real questions from the inbound log, in the words people used, and record the current answer for each one. Keep the wrong ones. That file is your baseline and it is the only way to show improvement rather than assert it.
Then re-ask all thirty after the edits and score each answer three ways: correct and complete, correct but incomplete, or wrong. Incomplete is the interesting category, because it usually means a condition is still buried somewhere, and it points at the specific paragraph to fix next.
Re-ask the same thirty after every significant document change, not just the first time. This takes twenty minutes and it catches the thing nobody expects, which is a fix to one document degrading an answer that used to work, because the new passage now competes with the old one. Two documents answering the same question differently is worse than one answering it badly.
And test as the populations who are not permanent employees. The scope failure is invisible until somebody asks from the wrong population, and by then it has happened to a real person.
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. You supply the data sources, it answers from them, cites what it drew on, and has a strict mode that declines rather than guesses when the corpus does not cover the question. Pricing is flat at $29, $69 and $199 a month with unlimited seats.
Relevant to this article: strict mode is what turns a document gap into a visible decline rather than an invented answer, which is the behaviour you want while you are still fixing documents. Its cons are unchanged: it has no free tier, it answers rather than actioning tickets, and it is not an HR or ITSM workflow platform. It will not improve a badly structured document, and no product on this list will.
SiteGPT
A document and site-trained answering agent, priced 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 quoting either figure without that qualifier misstates the price.
Relevant here: it is built around crawling site content, so it rewards exactly the structure this article argues for, and it is a poor fit if your documents live as files behind a login rather than as pages. It publishes support for 95+ languages.
Freshservice
Service management with Freddy AI over a knowledge base, at $19, $49 and $99 per agent per month plus a $29 per agent per month AI add-on.
Relevant here: the knowledge base is part of the product, which means the structure advice applies to articles you write inside the platform rather than to documents you point it at. That is a real advantage for consistency and a real constraint if your policies have to live somewhere else.
Zendesk
Mature help centre tooling with an AI layer. Suite Team is $55 per agent per month and the Copilot add-on is $50 per agent per month, so $105 per agent per month together.
Relevant here: the help centre article format is opinionated in a way that pushes you towards one topic per article, which is the right structure almost by accident. It was built for customer support content, so the internal HR framing takes configuration.
Crisp
A messaging platform with a lighter knowledge layer, priced per workspace at a free tier and then $45, $95 and $295 a month.
Relevant here: workspace pricing is unusual and suits a small team, and the knowledge layer is thinner than the dedicated answering products, so document structure matters more rather than less.
Leena AI and Moveworks
Both enterprise answering and actioning platforms with document ingestion as a core capability. Neither publishes a price and both sell with implementation attached.
Relevant here: implementation usually includes a content exercise, which is the work in this article done with help and on somebody else's schedule. That is genuinely valuable at several thousand employees and heavy at 200.
The Comparison
| Product | Where content lives | Declines when unsure | Pricing basis |
|---|---|---|---|
| Matram | Your sources, ingested | Yes, strict mode | Flat monthly, unlimited seats |
| SiteGPT | Crawled pages and files | Configurable | Monthly, or annual |
| Freshservice | Inside the platform | Configurable | Per agent, plus AI add-on |
| Zendesk | Inside the help centre | Configurable | Per agent, plus AI add-on |
| Crisp | Lighter, inside the tool | Limited | Per workspace |
| Leena AI | Your sources, with help | Yes | Quote only |
| Moveworks | Your sources, with help | Yes | Quote only |
The column that predicts answer quality is not on this table. It is whether your documents state one fact per paragraph.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Handbook is one long prose document | Any | Split the top twenty topics into pages | Averaged passages, vague answers | Split by topic before buying anything |
| Pay and benefits data in spreadsheets | Any | Export the needed rows as text | Numbers that do not exist to retrieval | Re-key those tables this week |
| Policies as designed PDFs only | Under 500 | Maintain a plain text source alongside | Partially recovered numbers | Make text the source, generate the PDF |
| Assistant declines a third of questions | Any | Read the decline log, fix top ten | Gaps read as product failure | Fix documents, not the model |
| Contractors getting employee answers | Any | Scope clause on every section | Scope stated once, retrieved never | Add the clause before the next intake |
| Policy changed last month | Any | Version note stating what and from when | Nobody can answer which rule applies | One line per change, dated |
| Nobody owns the documents | Any | Name an owner per document first | Wrong answers nobody can fix | Assign owners before restructuring |
| Content already one topic per page | 200 plus | Add dates, owners, question headings | Diminishing returns on structure | Testing and the gap log, not rewriting |
Three Things Not to Do
Do not write for the machine at the expense of the reader. Documents people cannot stand to read get ignored, and then nobody maintains them. Everything in this article happens to make documents better for humans too, which is not a coincidence, and anything that only helps retrieval is probably a mistake. Keyword lists, hidden text and repetitive phrasing all fall in this category.
Do not duplicate a policy across several documents. It feels helpful to restate the leave rules in the manager guide and the onboarding pack. Two passages now answer the same question, they will diverge within two quarters, and the assistant will sometimes return whichever one is stale. One source, referenced from elsewhere.
Do not delete the old version without a note. A policy that changed on a date still governs requests made before that date, and the commonest question after any change is which rule applies to something already in flight. Replacing the text silently removes the only information that answers it.
What Getting This Wrong Costs
The visible cost is a product that looks like it does not work, and the decision that usually follows is to switch products. The second product performs the same way, because the documents did not change, and the team concludes the category is immature. That is two evaluations and a year.
The quieter cost is the wrong answers that nobody reports. A declined question is a small annoyance and it is visible: it shows up in the log, somebody fixes a document. A confident wrong answer is invisible, and people act on it. Somebody books leave on the wrong notice, somebody misses an enrolment window, somebody tells a candidate the wrong probation terms. The document was the cause and the assistant was the mechanism, and the only reason the conversation reaches HR at all is that the consequence eventually does.
And there is the cost of doing the work twice. Teams that restructure without a baseline test set cannot tell which edits helped, so when answers are still imperfect they redo work that was already correct. A thirty-question baseline, recorded before any editing, is twenty minutes that saves a fortnight.
When You're Ready to Go Beyond Restructuring
Once the top twenty topics are one fact per paragraph, dated, owned and tested, the remaining gains come from different work.
Connect the systems of record. The questions that will not go away are the personal ones: my balance, my payslip, my submitted change. No document can answer those. That is an integration into the HR system, and it is worth scoping only after the document work is done, because document gaps are cheaper to fix and account for more volume.
Write the answers to questions you have no document for. The gap log fills with reasonable questions that no policy covers, because nobody ever wrote it down. Those are not retrieval failures. They are missing policies, and the log is the most honest list of them you will ever have.
Then review on a cycle rather than on complaint. Each document has an owner and a last-reviewed date, so a quarterly pass over anything older than a year is a short meeting rather than a project. The documents that drive the most answers get the most attention, which is the correct order and almost never the order a review cycle uses by default.
Frequently Asked Questions
How should an employee handbook be structured for an AI assistant?
One topic per page or per clearly headed section, with the answer in the first sentence under the heading, each condition on its own line rather than nested inside a sentence, and the subject named in the text rather than only in the heading above it. The practical test is whether a single paragraph lifted out of the document and read on its own still makes sense and still answers one specific question, because that is exactly what the retrieval layer will do with it.
Why does the assistant decline questions whose answers are in the handbook?
Almost always because the answer is a clause inside a paragraph about something else, so the passage holding it has an averaged meaning that matches no precise question well. Splitting that paragraph into a heading, a one-line answer and a short note about exceptions typically fixes the question in minutes, which is why the decline log is more useful as a list of documents to restructure than as evidence about the product.
Do we need to rewrite the whole handbook?
No, and attempting it is the commonest way this work fails to finish, because most of the effort lands on documents nobody ever asks about. Count one month of real questions, group them by what was being asked, fix the twenty topics that cover most of the volume, and let the unanswered-question log tell you what the next ten should be rather than guessing.
Can an AI assistant read tables and PDFs?
Generated PDFs are usually fine because the text is extractable, while tables depend entirely on how they were produced: an HTML table generally survives and a table inside a PDF often arrives as cells with no column association, which turns a pay band table into a meaningless list of numbers. Scans, screenshots and slide decks are effectively unreadable, and partial optical character recognition is worse than outright failure because a number recovered wrongly becomes a confident wrong answer with no visible cause.
Should headings be written as questions?
Where it reads naturally, yes, because a heading phrased the way people actually ask gives the retrieval layer close to an exact match and tends to produce a better answer than a formal policy title ever will. A document made entirely of question headings is hard for a person to scan, so the workable compromise is conventional section headings with question-shaped subheadings underneath them.
What happens to contractors and other populations?
They get answers written for permanent employees, confidently, unless the scope is attached to each section rather than stated once on an introductory page that never gets retrieved. One qualifying clause per section is enough, naming who the section covers and where other populations should look, and it prevents the worst category of wrong answer at almost no cost in effort.
How do we know whether restructuring improved anything?
Record the current answer to thirty real questions before you edit a single document, keep the wrong ones, and re-ask the same thirty afterwards, scoring each as correct and complete, correct but incomplete, or wrong. Without that baseline you cannot distinguish improvement from impression, and the incomplete category is the most useful of the three because it points at the specific paragraph where a condition is still buried.
What should go at the top of every policy document?
A last-reviewed date that somebody wrote deliberately rather than a file timestamp, a named owner or role who can fix a wrong answer, and where the policy has recently changed, one line saying what changed and from when. The date supports an honest caveat in the answer, the owner is what makes a gap assignable instead of merely discussed, and the change note answers the single most common question after any policy update.
HROpsLab takes no vendor money and publishes no paid placements.