Turn a Word Handbook Into a Searchable Knowledge Base
Every business of more than a handful of people has a version of the same document. A Word handbook. Forty pages, or eighty, or sometimes much more. The company's policies, procedures, expected behaviours, benefits, and practical how-to information, carefully assembled at some point and updated intermittently thereafter. Every new hire receives it as an attachment on their first day. Every new hire intends to read it. Almost nobody does.
What actually happens is more predictable. A few weeks in, a question arises. What is the policy on working from the office? How does the expense process work for purchases above five hundred pounds? What are the parental leave provisions? The new hire — or the not-so-new hire — remembers that the handbook covers this. They open their email, find the attachment, download it again, open the forty-page document, use Ctrl+F, search for the relevant word, scroll, hope the right section is in there, give up, and email HR.
HR answers the question. The handbook has, in that moment, failed. Not because the content was wrong — usually the content is correct — but because the container made the content harder to retrieve than the alternative of asking another human being. Over time, HR becomes the search engine for the handbook. The original purpose — a self-serve reference — never actually materialises.
The content in the handbook is not the problem. The Word file is.
The walkthrough, with real timestamps
Our example is a forty-two-page employee handbook for a professional services firm. It has eleven sections — from the firm's values through working arrangements, leave, performance, expenses, IT, and an appendix of policies. It is the kind of document every HR lead has written a version of at some point.
0:00 — Upload the Word handbook. The .docx file is dropped onto the upload area. The parser reads through the document.
1:30 — Exepad parses the document structure. Headings become section anchors. Sub-headings become page boundaries. Tables — of which an HR handbook has many, for things like leave allowances and expense thresholds — are preserved as tables, not flattened to prose. Images and embedded diagrams are kept in place. Cross-references inside the document ("see section 4.3") become proper internal links that navigate rather than forcing the reader to hunt.
3:00 — Review the proposed knowledge base structure. A table of contents appears on the left. Each section of the handbook is listed as a category. Sub-headings within each section are individual pages. A search bar sits along the top. The current page renders in the main area. You click through three or four sections to check that the parse is sensible. For a reasonably structured handbook it will be.
5:00 — Refine. Rename one section — the existing "Working Arrangements" heading is dry, "How we work" reads better. Merge two short sub-sections that really belong together. Add a tag to the three policies that are compliance-relevant, so a compliance officer can later filter to just those. Add a short "Quick links" block on the home page pointing at the five most-asked topics — working hours, expenses, leave, benefits, IT support — so the common questions have an obvious entry point before search.
7:00 — Publish with team access. The knowledge base goes live at your internal URL. You invite the whole team. You also set permissions — some sections, like the compensation appendix, are visible to managers only. A contractor-specific view is created that hides internal-only policies.
The handbook, which has been sitting on a drive, retires. The same content is now reachable in three seconds by anyone who needs it.
What the published knowledge base can do
The knowledge base is the same content as the handbook. What changes is what the team can do with it. A few capabilities, once they exist, are surprisingly hard to imagine living without.
Full-text search. The search bar looks across every page of every section. A query for sick leave returns the three places the handbook covers sick leave — the summary page, the detailed procedure, the appendix of policy references — with context snippets. The team member lands on the right section in seconds, not minutes.
Browseable table of contents. The left-hand navigation shows the entire structure of the knowledge base at a glance. Team members who prefer to browse rather than search can see what is there. The cognitive step of "is this covered?" becomes a glance rather than a search-and-hope.
Mobile access. A phone is the only thing a new hire has with them when the question arises during a commute, at lunch, or at a client site. The knowledge base reflows for a phone. The search bar is thumb-reachable. The page you land on is readable. A PDF handbook on a phone is a different artefact — mostly a source of squinting.
Always the latest version. When a policy changes, the change is made in one place. The knowledge base updates. Every team member is on the current version from the moment they next open the link. The old problem — "is this the handbook I got last year, or the new one?" — disappears, because the handbook is not a file anymore.
Permissions and scoping. The same knowledge base can serve different audiences with different views. Full employees see everything. Contractors see the sections relevant to them. Managers see an additional set of pages, including things like the compensation framework. The segmentation is explicit and enforced, so the problem of a sensitive policy being inadvertently emailed to the wrong group largely goes away.
Feedback per section. Every page carries a small was this clear? control. When a team member finds a section confusing, they can flag it on the spot. The HR lead gets a steady stream of specific, actionable feedback — "the expense approval threshold section needs an example" — tagged to the exact page, rather than a once-a-year survey. The knowledge base improves over time because the people who use it tell it where to improve.
Which handbooks work best
Not every long Word document is a handbook in disguise. The process below works best with documents that already have a clear structure — not documents that were written as a single narrative.
Good fits. Employee handbooks. Standard operating procedures. Training references. Consulting deliverable libraries. Product documentation. Sales playbooks. Internal methodology guides. Anything where the underlying content is organised into sections and the primary way people will use it is look things up.
Less good fits. Long-form narratives that are meant to be read start-to-finish rather than referenced. White papers. Thought-leadership documents. Marketing brochures, which are better served by the PDF-to-website walkthrough.
Sometimes a better fit for a different output. A handbook that the team is expected to work through rather than reference — a structured onboarding programme, a certification-style learning path — is usually better as a training app. The training-deck-to-learning-app walkthrough covers that adjacent case. The rule of thumb is whether the user is expected to browse and search (knowledge base) or progress through (training app).
What changes in the first month
Teams that move from a Word handbook to a knowledge base notice two specific effects within the first thirty days, and a third over the quarter.
In the first week, the volume of small "what is the policy on…?" questions to HR drops noticeably. Not to zero — some questions genuinely require interpretation, and HR is still the right place for those — but the easy ones stop arriving, because the person who would have asked them has found the answer themselves.
In the first month, the HR lead's inbox becomes a better reflection of what HR actually needs to work on. The questions that arrive are the ones that genuinely need a human. The tedious lookups are gone. HR's week reshapes around the more substantive work that was previously crowded out.
In the first quarter, the knowledge base itself starts improving. The feedback control, used steadily, surfaces the ambiguous sections. The HR lead rewrites them as they are flagged. Onboarding of new hires speeds up, because the document the new hires are being handed is now actually usable. The "did you read the handbook?" question stops being rhetorical.
Getting started
If your handbook, SOP document, or reference guide is currently a Word file sitting on a shared drive, the fastest way to see whether a knowledge base is a better home is to upload it. The original file stays intact. The knowledge base is a separate artefact; you can preview it, show it to one colleague, and decide whether to invite the rest of the team before anything goes further.
If your document is closer to a manual — technical, reference-heavy, diagram-dense — the PDF-to-app walkthrough is a useful companion. If the document is part of a larger knowledge problem inside a consulting firm, the practical guide for consulting firms puts this specific walkthrough inside its wider operational context. And the PowerPoint-to-training-app walkthrough covers the case where the content is designed to be worked through rather than referenced.
The tool page, with examples of knowledge bases published from Word handbooks, is at /convert-word-to-knowledge-base.
