Automating corporate knowledge search

Consider a company where a new employee needs to find out how to handle a non-standard customer refund.

They open a shared company folder and try to find the instructions. It contains several documents with similar names: an old procedure, a new PDF, a department checklist, and a file without a clear date.

The answer is not immediately available.

The employee searches their email for words such as “refund”, “exception”, and “approval”. They then browse work chats, ask colleagues, and receive several different answers.

One colleague remembers that the rule changed six months ago. Another sends a document. A third says that additional approval from the finance team is required.

Much of the time therefore goes into finding an answer and establishing which source is current rather than doing the work.

This situation recurs with internal procedures, technical documentation, customer service rules, product information, contracts, instructions, glossaries, and accumulated answers from specialists.

It is especially difficult for new employees: experienced colleagues sometimes know where to look, while a newcomer may not even know whether the required document exists.

A typical process looks like this:

Company knowledge remains fragmented, and experienced employees are repeatedly interrupted by the same questions.

The system first connects to authorized sources of corporate knowledge: document folders, PDFs, Word and Excel files, internal databases, glossaries, and other repositories.

Python-script retrieves documents, extracts their text, and saves additional information: file name, section, date, source, version, and other metadata.

Large documents are split into small, meaningful passages. For each passage, embedding-model creates a numerical representation of the text's meaning, and the data is then stored in PostgreSQL + pgvector.

The system can therefore search beyond exact word matches.

For example, an employee asks:

How do I process a refund for a corporate customer if the invoice has already been paid?

The documents may not contain this exact phrase at all. They may instead use terms such as “return of funds”, “legal entity”, “paid order”, and “payment approval”.

vector-search finds passages whose meaning is close to the user's question.

The retrieved context is passed to text-LLM-model, which produces a clear answer based only on the corporate materials found.

The system can show the sources alongside the answer:

• Refund policy.pdf — section 4.2
• Financial rules.docx — section 7
• CRM glossary — term: Refund

This fundamentally distinguishes a corporate knowledge base from an ordinary chatbot. The model should not simply “know something”. It receives specific internal company documents and bases its answer on them.

A search that previously took minutes or even hours can take a few seconds.

Suppose a company has a sales team, a support team, and an accounting department.

Employees regularly ask:

• Which documents are needed for a new customer?
• What payment term applies to this type of contract?
• What should I do if a customer is late with payment?
• Can an order be changed after an invoice has been issued?
• How do I process a refund?
• How do I create this kind of deal correctly in the CRM?
• Which version of the instructions is current?

Today, the answers may be spread across dozens of files.

After a corporate knowledge base is introduced, the employee simply writes:

What should I do if a customer wants to change an order after payment?

Within a few seconds, the system finds the relevant rules and answers:

1. Check the order status in the CRM.
2. If shipping has not started, create a change request.
3. A price change requires renewed approval.
4. After approval, update the order in the ERP.

Sources:

• Order processing procedure, section 8.3
• CRM instructions, section 5.1

The employee does not need to know where these documents are physically stored.

A corporate knowledge base should not be static.

For example:

The same process can run on a schedule:

The system therefore always provides a current, unified interface to company knowledge.

For a corporate knowledge base, preserving the connection between the answer and the source document is especially important.

Each passage can retain:

• Source
• Document title
• Section
• Date
• Version
• Last updated date
• Document owner
• Access level

If conflicting instructions are found, the system does not have to choose one on its own.

It can report:

This is much safer than confidently generating an answer when there is insufficient data.

In a real corporate system, not all knowledge should be available to every employee.

The pipeline can therefore account for user permissions:

For example:

• Sales → sales team instructions
• Finance → financial documents
• HR → HR rules
• Management → management documentation

The same search interface can work with different sets of information depending on access permissions.

• company instructions;
• policies and procedures;
• technical documentation;
• product knowledge bases;
• onboarding new employees;
• internal Help Desk;
• support team answer databases;
• legal and contractual documents;
• CRM and ERP instructions;
• IT department documentation;
• internal standards;
• terminology databases and glossaries;
• project documentation;
• accumulated solutions to common problems.

Once the knowledge base is built, the same pipeline can be developed further.

For example:

Or:

In a more advanced version, the corporate assistant can provide information and also launch an authorized business process:

A corporate knowledge base can therefore become a universal interface between employees and the company's internal systems.