The HR team at a 300-person company was spending a significant portion of their time answering the same questions repeatedly. Holiday policy, parental leave, expense reimbursement, onboarding steps. Every employee had these questions at some point, and there was no self-service way to answer them. Employees waited days for simple answers. HR couldn't do higher-value work because they were buried in repetitive queries. The solution felt obvious: build a chatbot on the internal HR documentation. But the challenge wasn't technical. It was trust. Employees needed to believe the answers were correct. One wrong answer about a legal entitlement would destroy confidence in the whole system.
I started by mapping the actual query distribution. Not what HR thought people asked, but what they actually asked. I went through six months of HR email threads and categorised every question. Eighty percent of the query volume came from twelve topic clusters. That told us exactly what the chatbot needed to handle well. We built a RAG (retrieval-augmented generation) prototype against the existing HR documentation library. Before showing it to anyone, I ran it against the twelve topic clusters internally, testing every edge case, every ambiguity, every place where the docs were unclear. We identified and fixed the documentation gaps before they became chatbot errors. The rollout was phased: first to a small pilot group of 20 people who understood they were testing something early, then to a broader group, then org-wide. Each phase had explicit feedback loops: a simple thumbs down rating that flagged low-confidence answers for HR review. This meant the system improved continuously and employees saw their feedback actually changing outputs.
About three weeks into the pilot, an employee asked about a fairly complex scenario: parental leave combined with a timing edge case around the annual bonus cycle. In the old world, this would have gone to HR, taken two days to answer, and possibly involved a consultation with legal. The chatbot answered it correctly, cited the relevant policy documents, and explained the calculation. The employee posted about it in the company Slack. That moment shifted internal perception from "it's a chatbot" to "it actually knows the policies." Adoption accelerated significantly after that.
We underestimated how much the documentation itself would be the bottleneck. Several topic areas had outdated, contradictory, or just vague policy documents. The chatbot faithfully reproduced the confusion that was already in the docs. We ended up doing a documentation quality audit mid-project. Not something we'd planned for, but it was necessary.
Run the documentation audit before building the chatbot, not during. The RAG approach is only as good as the source material. Spending two weeks cleaning up the HR documentation before we started building would have been faster than discovering the gaps through failed test cases.
HR had strong opinions about what employees asked. The data disagreed. Some topics HR thought were common barely appeared, and some they'd overlooked were top of the list. Building against the actual distribution meant we prioritised correctly.
A hard launch to 300 people with one wrong answer about a legal entitlement would have killed trust permanently. The phased approach meant errors were caught in small groups where we could fix them before they became reputation-defining incidents.
Employees needed to be able to verify answers themselves. Showing the source document for every response meant people could check the chatbot's work. This built trust faster than any amount of internal messaging about accuracy.