The problem was not the absence of a chatbot

Wilhelm-Klein is a medium-sized German distributor of hygiene and healthcare products. After a sharp rise in demand, it expanded its workforce, catalogue, warehouse operations and logistics. Working practices changed faster than instructions could be updated. According to the European Digital Innovation Hubs Network case study, employees duplicated work, used workarounds for awkward procedures, and placed growing demands on internal support. The existing ERP system also no longer fitted new roles and processes well.

A tempting response is to buy “AI search across all files.” Yet searching contradictory or outdated documents can produce a fast, confident, obsolete answer. The project therefore began by observing actual work: who creates procedures, which workarounds appeared, and where an employee cannot clarify an ambiguous step with the document's author. The same issue is familiar to smaller firms: knowledge about purchasing, returns and dispatch often lives in email, folders and conversations rather than one maintained knowledge base.

What the team actually did

The old file-based system was moved to a corporate SharePoint intranet, with roles and categories introduced. This was more than a technical migration: each document needs an owner, a clear scope and defined readers. The team then built a demonstrator with two interfaces side by side, one using DeBERTa and the other a generative GPT-based model. For more than two months, employees compared multi-document search, contextual and non-contextual answers, confidence scoring, links back to source passages, and the ability to contact document authors.

The team ultimately chose the generative approach with answer traceability and feedback features. An employee could check which documents contributed to an answer, ask a follow-up question, or propose a correction to the source. That is a crucial RAG loop: a wrong answer must not disappear inside a chat; it should become a signal to the person responsible for the knowledge. Future users from operational teams, not only managers, tested the system.

The EDIH account says the final infrastructure is being deployed in the company's internal environment using its own hosting resources and a licensed model subscription. That is not the same as an entirely local AI stack: the application's location, the source documents' location, and the model's data-processing terms need separate verification. This specific case also moved the document repository to cloud-based SharePoint.

What counts as a result — and what does not

The source says evaluation during testing indicated an *expected* reduction of more than 60% in internal IT support tickets and an *expected* 50% rise in engagement with knowledge and document management. These are not confirmed outcomes from long-term production operation. The public account does not provide the counting method, the starting ticket volume, a control group or a full cost calculation. The confirmed conclusion is narrower but still useful: a two-month pilot was run, an approach was chosen, and deployment with own hosting and a subscription began.

Employee feedback changed not only the interface but the underlying documents. The case authors found incomplete and outdated procedures. The right metrics are therefore not how many answers the bot produces, but the share of questions resolved correctly with verifiable sources, repeat support contacts, and the ongoing effort to maintain the knowledge base.

How another business can apply the idea

There is no need to copy SharePoint or the selected model. If a company already has a file server, document-management system or knowledge base, first check whether documents can be extracted with metadata and access rights. A minimal pilot architecture is:

  • assign an owner, version and review date to each group of procedures;
  • index only approved documents while retaining links to originals and access restrictions;
  • retrieve relevant passages and pass them to the model with the question;
  • show the answer with specific sources, and route weakly supported questions to a person;
  • send corrections to the document owner rather than “fine-tuning” the model on every complaint.

If data must remain inside a protected environment, place the index and model there and check separately where logs, backups and telemetry go. If using an external API, agree on data classes and contractual conditions first. Microsoft notes that SharePoint search respects readers' permissions; a custom RAG connector must preserve that property at every stage, or the bot could reveal a passage to someone who may not read the original document.

Economics without an invented return on investment

The case does not publish a reliable project cost, so the following is only a model calculation for deciding whether to pilot. Assumptions: 50 repeated internal questions a week, 12 minutes of specialist time each; the system correctly covers 20 questions, and an employee spends 3 minutes checking each answer. Potential time freed is `(12 − 3) × 20 = 180 minutes`, or 3 hours a week. If document maintenance takes 2 hours, only one hour remains before licensing, infrastructure, support and error costs. With poor source quality, a pilot may not pay back at all.

A manager needs a measurement of their own queue, not a promised automation percentage. Over two weeks, collect 30–50 recurring questions, processing time and the documents experts used. Mark obsolete procedures and restricted sections. Then compare ordinary search, RAG with a local model and, only if data policy permits, an external-model option on the same questions. Success means a correct answer with the right source and respected access controls, not an impressive demo.

Limits of the approach

RAG does not fix an ERP system, resolve conflict between real practice and a formal procedure, or replace the owner of organizational knowledge. A generative model can misinterpret even a retrieved document; a confidence score is not a guarantee of truth. Teams need source versions, test questions, an error log, a way for employees to challenge answers, and escalation to a human for costly or risky decisions. NIST's generative-AI risk guidance supports this approach: evaluate the system in its application context and manage errors throughout its lifecycle.

The next step can be small: choose one process, such as returns or onboarding, and clean up the ten most-used procedures. If ordinary search already solves the problem, a complex agent is unnecessary. If questions require synthesizing several current documents, RAG then has a justified place in the architecture.