Build an HR-Policy Q&A Bot: Employees Ask, Claude Answers

A 280-person Bengaluru services firm had one HR generalist answering the same 15 questions all day: how many casual leaves are left, what's the notice period, can I claim a Wi-Fi reimbursement. We built a document-Q&A bot over their handbook in a weekend. It answers from the policy text, cites the exact clause, refuses to guess, and routes anything sensitive to a human. After a month, routine HR queries to the inbox dropped by roughly 60%. This post is the build — ingestion, access scoping, the citation-to-clause pattern, and the guardrail that stops it inventing policy. ## The Answer in 60 Words Build a retrieval-augmented bot: chunk your HR handbook by section, embed the chunks into a vector store, and at query time retrieve the top matches and hand them to Claude with a strict instruction to answer only from the supplied text and cite the clause. If retrieval finds nothing relevant, the bot says it doesn't know and offers to escalate to HR. Scope access so people see only their own policies. ## Why This Matters Now (June 2025) Off-the-shelf chatbots hallucinate, and a hallucinated HR answer is a real liability — telling an employee they have leave they don't, or a reimbursement they can't claim, erodes trust fast. Retrieval-augmented generation (RAG) fixes this by grounding every answer in your actual handbook text and forcing a citation. The technique is now cheap and well-understood: a small vector store plus a capable model like Claude. The new part for HR is the discipline — citation-to-clause and a hard "I don't know" — not the plumbing. ## What You'll Need (Prerequisites)

• Your HR handbook as clean text or Markdown (export the PDF, fix the headings)
• A vector store — pgvector on Postgres works well and keeps data on your own infra
• An embedding model and the Claude API for generation (tested June 2025)
• A way to identify the employee asking — so access scoping and personalised data work
• A chat surface: a Slack app, a Teams bot, or a simple internal web page
• An escalation channel into the HR inbox or ticket queue

## The Architecture As Hrishikesh, our CTO, puts it: a good HR bot is mostly a good librarian. It finds the right page, reads it back accurately, and knows when to fetch a person. The cleverness is in restraint, not generation. ## The DIY Walkthrough The retrieval query is a similarity search filtered by the asker's role. Here is the shape of it in pgvector:

-- Retrieve top 5 relevant clauses the asker is allowed to see
  SELECT clause_no, heading, body
  FROM hr_chunks
  WHERE audience = ANY (:user_roles)        -- access scoping
  ORDER BY embedding <=> :question_embedding -- cosine distance
  LIMIT 5;

The audience = ANY(:user_roles) filter is the access-scoping guard. A junior employee's roles might be ['all-staff', 'india']; a manager's might add 'managers'. The retriever simply never returns a clause the asker is not entitled to see, so scoping is enforced at retrieval, not left to the model to remember. Here is the system prompt we ship, lightly trimmed:

You are an HR policy assistant. Answer ONLY using the policy
  clauses provided below. Do not use any outside knowledge or
  make assumptions about policy.
  
  Rules:
  1. Every answer must cite the clause, e.g. "Source: Section 4.2".
  2. If the clauses do not contain the answer, reply exactly:
     "I can't find that in the handbook. I'll connect you with HR."
  3. For grievances, harassment, termination, or disputes, do NOT
     answer. Reply: "This needs a person. Connecting you to HR."
  4. Never quote a clause the user was not shown.
  
  Policy clauses:
  {retrieved_chunks}

## The Citation-to-Clause Pattern (Why It's Non-Negotiable) Every answer the bot gives ends with a source line that links to the exact clause. This does three things at once: it lets the employee verify the answer themselves, it lets HR audit what the bot is telling people, and it makes the bot's confidence honest — if it can't point to a clause, it isn't allowed to answer. Compare the two replies: | Without citation | With citation-to-clause | |---|---| | "You get 12 casual leaves a year." | "You have 12 casual leaves per calendar year, accrued monthly. Source: Section 4.2, Leave Policy." | | Unverifiable; could be a hallucination | Checkable in one click; auditable by HR | The second answer is the only acceptable one for HR. This is the same discipline we apply across our retrieval builds — for the deeper engineering version over help docs, see our weekend RAG chatbot tutorial, and for a multilingual variant, our Hindi-English-Tamil chatbot build. ## Common Mistakes (When HR Bots Go Wrong) Symptom: "The bot confidently stated a policy that doesn't exist." Cause: weak or missing grounding — the model fell back on training data. Fix: the strict system prompt above, plus an eval set that specifically tests out-of-handbook questions for a correct "I don't know." Symptom: "A junior employee saw a manager-only clause." Cause: access scoping done in the prompt instead of at retrieval. Fix: filter by role in the retrieval query itself, as in the pgvector example. The model can't leak a clause it was never given. Symptom: "Answers are vague because chunks are too big." Cause: chunking by large sections drowns the relevant sentence. Fix: chunk by sub-section so retrieval returns tight, specific clauses. Symptom: "The bot answered a harassment question." Cause: no hard rule for sensitive topics. Fix: a rule-based escalation that fires before generation on a defined list of sensitive subjects — never rely on the model to self-censor. ## When Not to Build This Skip the bot if your handbook is under ~10 pages and rarely consulted — a well-organised PDF and a search box is simpler and cheaper. Skip it too if your policies change weekly and nobody owns keeping the source document current; a RAG bot is only as good as its handbook, and a stale source produces confidently wrong answers. This build pays off when you have a substantial, stable handbook, a sizeable headcount asking repetitive questions, and an HR team whose time is worth protecting — the exact shape of the Bengaluru firm below. ## Real Example: A 280-Person Services Firm The firm's single HR generalist spent an estimated third of her week on repeat questions — leave balances, notice periods, reimbursement rules, WFH policy. None of it needed her judgement; all of it needed the handbook, which most employees never opened. We ingested their 64-page handbook over a weekend, chunked it by clause, scoped manager-only sections behind a role tag, and put the bot in Slack. The grounding prompt and the citation-to-clause pattern did the heavy lifting; the eval set caught two early cases where the bot tried to answer a reimbursement edge case it should have escalated. A month in, routine queries to the HR inbox were down roughly 60%, and the generalist redirected that time to onboarding and the cases that actually needed a person. We build these for clients through our AI and automation practice, on the same retrieval stack we use for customer-facing support bots — and the same internal-tooling discipline behind builds like AppliedView, a professional-development platform where structured, verifiable feedback was the whole point. The same grounding-and-citation discipline runs through our in-house products — on TalkDrill, our English-speaking app, we hold AI feedback to a verifiable standard rather than letting a model freestyle, because a confident wrong answer costs trust in exactly the same way. ## FAQ ### How do I stop the HR bot from making up policy? Ground it with RAG and a strict system prompt. The model may answer only from clauses you retrieve from the handbook, must cite the clause, and must say "I don't know" when retrieval finds nothing relevant. Removing the model's freedom to improvise is what stops hallucinated policy. ### How does access scoping work so juniors don't see manager-only clauses? Tag each handbook chunk with an audience — all-staff, managers, region — and filter the retrieval query by the asker's roles. The model only ever receives clauses the person is entitled to see, so it cannot leak a manager-only clause. Scoping is enforced at retrieval, not by trusting the model. ### What should the bot do with sensitive questions like harassment or termination? Escalate, never answer. Hard-code a list of sensitive topics — grievance, harassment, termination, disputes — that trigger an immediate handoff to a human, bypassing generation entirely. These cases need empathy and legal care, not an automated reply, even a correct one. ### How long does it take to build an HR-policy Q&A bot? A focused weekend for a first working version: ingest and chunk the handbook, set up a pgvector store, write the grounding prompt, and wire a Slack surface plus an escalation path. Tuning chunking, scoping, and the eval set to production quality typically takes another few days. ### Where is the employee data stored — is it safe? Use a self-hosted vector store like pgvector on your own Postgres so handbook content and queries stay on your infrastructure. Identify employees through your existing SSO for access scoping. Keeping policy data off third-party stores is usually a requirement HR and legal will insist on. ### What does "citation-to-clause" mean and why does it matter? It means every answer links to the exact handbook clause it used, like "Source: Section 4.2, Leave Policy." It lets employees verify answers, lets HR audit what the bot says, and keeps the bot honest — if it can't cite a clause, it isn't allowed to answer. It is the single feature that earns HR's trust. ### Which model should I use for an HR bot? A capable instruction-following model like Claude works well, because the task rewards strict adherence to the grounding rules over raw creativity. The model matters less than the retrieval quality and the system prompt — a strong model with weak grounding still hallucinates, while a solid setup keeps answers reliable.