"Where is the latest SOP for stock opname?" "How many days of leave do I get after probation?" "Is this unit still under warranty if the seal is broken?" In most companies, questions like these land in the same few WhatsApp chats every week, and the people who know the answers spend hours repeating themselves.
An internal knowledge chatbot answers those questions from your own documents: SOPs, HR policies, product manuals, pricing rules and internal memos. Employees ask in Bahasa Indonesia or English, and the bot replies with a short answer plus a link to the exact document and section it used. It does not replace your documents. It makes them findable.
The technology is mature enough for a focused pilot today. The harder truth is that answer quality depends far more on your documents, permissions and testing than on which AI model you choose. This guide walks through the build in the order that matters.
How an internal knowledge chatbot works
Most internal chatbots use retrieval augmented generation. When someone asks a question, the system searches your document collection for the most relevant passages, then hands those passages to a large language model with instructions to answer only from them and to cite the source. Our explainer on how retrieval augmented generation works covers the mechanics in more depth.
Two points surprise many teams. First, the model does not "learn" your documents in the training sense, so updating a policy means re-indexing a file, not retraining anything. Second, the bot only knows what is written down. If your return policy lives in one supervisor's head, the chatbot cannot answer it, and the project will expose that gap quickly.
Good first use cases
| Department | Typical questions | Source documents | Watch out for |
|---|---|---|---|
| HR | Leave rules, BPJS enrollment steps, reimbursement limits | Employee handbook, company regulations, HR memos | Personal cases should go to a person |
| Sales and customer service | Product specs, warranty terms, discount rules | Catalogs, warranty policy, pricing guidelines | Prices and promos change often |
| Operations | SOP steps, checklists, troubleshooting | SOPs, machine manuals, work instructions | Safety steps must be quoted exactly |
| IT helpdesk | VPN setup, password resets, device requests | IT guides and FAQs | Low risk, a good first pilot |
| Finance | Approval limits, tax invoice procedures | Finance SOPs, approval matrix | Answers must reflect the current version |
Pick one department for the pilot. A narrow scope gives you a clean document set, a clear owner and real questions you can test against.
Step 1: Prepare the documents first
Document preparation decides most of the answer quality. A chatbot built on three versions of the same SOP, with file names like "SOP Gudang final revisi 2 FIX.pdf", will confidently quote the wrong one.
Work through this checklist for the pilot scope:
- Inventory the sources. Shared drives, Google Drive, SharePoint, email attachments and files that only circulate in WhatsApp groups
- Remove duplicates and outdated versions. Keep one current version per topic and archive the rest outside the index
- Assign an owner per document set. Someone in HR owns HR answers. Without an owner, nobody fixes wrong answers
- Add metadata. Department, effective date, version and confidentiality level. The bot can then show the effective date in every answer
- Handle scanned files. Scanned PDFs need OCR first; our guide to OCR and document AI explains the options
- Convert tables and diagrams. Price tables in Excel and flowcharts saved as images need special parsing, or a short text version written by the owner
- Test the language mix. If documents are in Bahasa Indonesia and English, test retrieval with questions in both, including the mixed phrasing people actually type
Step 2: Design access control from day one
The fastest way to lose trust in an internal chatbot is for a staff member to ask about bonuses and receive a passage from the management pay guideline. Access control has to live inside retrieval, not in the chat window.
In practice, every indexed passage carries the permissions of its source document, and search only returns passages the person is allowed to open. The cleanest setup syncs permissions from Google Workspace or Microsoft 365 groups, so you do not maintain a second list. Documents with mixed sensitivity should be split or kept out of the index.
Personal data needs its own decisions. Indonesia's Personal Data Protection Law (Law No. 27 of 2022, or UU PDP), whose two-year transition period ended in October 2024, applies to employee data as much as customer data. Keep personnel files out of the index unless there is a clear purpose, restrict who can read question logs, and document where data is processed. Our guide to UU PDP compliance for apps covers the obligations.
Where the model runs is part of the same decision. Commercial AI APIs are quick to start with; check their data retention terms, whether inputs are used for training and which region processes the data. Self-hosted open-weight models keep data inside your environment but need GPU capacity and more engineering. We compare both routes in open-source LLMs vs commercial APIs.
Step 3: Build the retrieval pipeline
A production chatbot has more moving parts than a demo. A typical pipeline looks like this:
- Connectors pull files from Google Drive, SharePoint or a document system and detect changes
- Parsing and OCR turn PDFs, Word files, spreadsheets and scans into clean text with headings preserved
- Chunking splits documents along their structure, such as one SOP step or one policy article per passage, rather than at arbitrary character counts
- Indexing stores each passage as an embedding vector, for example in PostgreSQL with the pgvector extension or a managed vector database, together with its metadata and permissions
- Hybrid search combines vector search with keyword search. Keyword matching matters for product codes, SKU numbers and references like "Pasal 12" that semantic search can blur
- Re-ranking reorders the top results so the most relevant passages reach the model
- Answer generation uses a prompt that requires citations, forbids guessing and tells the model to say when the documents do not cover the question
- Feedback capture records a thumbs up or down with an optional reason, so document owners see which answers fail
Put the bot where people already ask questions: Microsoft Teams, Google Chat, Slack or a simple intranet page. WhatsApp is possible through the WhatsApp Business Platform, but messages then pass through Meta's infrastructure, so weigh that against the sensitivity of your documents.
The answering rules deserve care too. Clear instructions on tone, citation format and refusals make answers consistent, and our guide to prompt engineering for teams shows how to write and version them.
Step 4: Test accuracy with real questions
Do not judge the chatbot by a demo. Judge it by an evaluation set: real questions collected from HR tickets, helpdesk emails and WhatsApp chats, each paired with the expected answer and the document it should come from. For a first pilot, aim for 50 to 150 questions that cover the main topics. That is enough to reveal where retrieval or the documents are weak.
| Test | What you check | Example |
|---|---|---|
| Retrieval | Did search return the right document and section? | "Batas reimburse kacamata berapa?" returns the benefits policy |
| Correctness | Is the answer right and complete? | Leave entitlement includes the probation rule |
| Citation | Does the link point to the passage used? | The link opens the correct SOP step |
| Refusal | Does it admit when documents are silent? | Asked about an unwritten policy, it says so and names the owner |
| Permission | Can a staff account reach restricted content? | A question about director bonuses returns nothing restricted |
Agree on pass criteria with the document owners before the pilot, then rerun the same set after every change to documents, prompts or models. After launch, review a sample of real conversations each week. A low-rated answer often points to a missing or unclear document rather than a model problem.
Costs, timeline and common pitfalls
The main cost drivers are the number and messiness of sources, permission complexity, the chat channels you integrate, the hosting choice and the time owners spend fixing documents. Commercial APIs bill by usage, so cost grows with the number of questions and the length of passages sent. Self-hosted models shift the cost to servers and maintenance.
As a rough planning range, assuming one department, a few hundred reasonably clean documents, one chat channel and a commercial API, a pilot takes about 4 to 8 weeks for a team of two to three people. Messy scans, many permission groups or several languages extend that.
Watch for these pitfalls:
- Indexing the whole shared drive at once instead of a curated scope
- No document owner, so wrong answers never get fixed
- No "I don't know" behavior, which invites confident guesses
- Permissions added after the demo instead of designed in
- Measuring success by the number of chats rather than questions resolved without escalation
How Weaveward can build this for you
We would start with a short document audit for one department, then connect your Google Drive or SharePoint, set up permission-aware retrieval and deliver a pilot inside the chat tool your team already uses. Before wider rollout, we validate the bot against an evaluation set built from your real questions, with pass criteria agreed with your document owners.
If you want a knowledge assistant that cites its sources and respects access rules, explore our AI solutions for business teams or talk to our team about a pilot scope.