When the manual exists but the answer is slow

A technical question to an electronics manufacturer rarely fits into a single FAQ entry. Someone must identify the product variant, find the current documentation, and explain exactly what it supports. When only one experienced specialist knows where to look, the customer waits for a callback while colleagues search the same manual again.

German company ehb electronics faced this process. According to the Hanover region's economic development agency, technical requests previously required experienced staff and sometimes a follow-up contact with the customer. Working with the KI.WI network and implementation partner deepIng, the company introduced an assistant that searches existing product documentation. It answers technical questions around the clock and in multiple languages; staff use it during consultations, and customers can use it on the website. The company calls it ehbuddy.

This is a documented example of a support workflow change, not proof of a particular return on investment. Public sources disclose no request volume, answer accuracy, time savings, model, retrieval method, or hosting location. Below, we separate what is known about the case from an editorial implementation design that a Russian small business could test with its own data.

What the case actually establishes

The regional agency describes three practical attributes: searching existing product documentation, multilingual availability around the clock, and two channels of use—by support staff and by customers on the website. deepIng likewise describes search over technical documents and use for internal and external questions. Both sources describe better access to knowledge, but neither provides independently measured answer quality or a service-level agreement.

There is an organizational detail worth noticing: the rollout included staff training and workshops. Otherwise, a bot can become another window into which people manually copy answers. The more useful unit of analysis is not “AI responds” but “approved document—retrieved passage—checked answer—specialist feedback.”

Do not call ehbuddy an on-premises model or a RAG system: the primary sources do not disclose that architecture. For a Russian company, local RAG is one possible way to implement a similar workflow, not a reported feature of the German case.

Adapting the workflow for a small company

Start with one product family or one class of request. A service team might, for example, select questions about controller and sensor compatibility. Inputs would be current manuals, variant tables, change bulletins, and engineer-approved answers. Every file needs a version, an owner, an effective date, and a designation of whether customers may see it or only employees may.

A proposed design is straightforward:

  • A customer or operator asks a question, including the model number and firmware version where relevant.
  • Retrieval selects passages only from authorized, current documents. Different roles have separate collections or access filters.
  • The model drafts an answer citing the document title, version, and section. If sources conflict or information is insufficient, it does not guess; it escalates to a specialist.
  • The specialist corrects an inaccurate answer in the source document or approved knowledge base; the question log reveals recurring documentation gaps.

The robot may enthusiastically bring five manuals instead of one, but retrieval rules—not the model's eloquence—must select the relevant, permissible evidence. A customer-facing assistant particularly needs an access boundary: internal prices, contract terms, service notes, and personal data must not enter the public index.

An on-premises setup makes sense when technical documents cannot be sent to an external provider or when predictable integration with internal systems matters. It is not mandatory in every case: if manuals are public and request volume is low, a cloud service may be simpler. Choose after classifying the data and calculating the workload, not because “local” sounds attractive.

Data, integrations, and infrastructure

A minimum pilot does not require connecting the entire ERP system. An export of approved PDF and HTML documents, a product list, and a simple question channel can be enough. Staff might use an internal web form; customers could use a restricted test page until answers pass review. A CRM integration becomes useful once the rules for handing a difficult request to a person are clear.

Before indexing, remove duplicates and obsolete revisions. A product-variant table in a PDF can be extracted as unrelated lines; check such files manually. For “does version A work with B?”, an incorrect row is worse than an honest refusal. Showing the supporting passage beside the answer lets an engineer verify its meaning quickly.

A local setup needs document storage, a search index, an answer model, an event log, and rules for refreshing the knowledge base. GPU and memory requirements depend on the model, question length, concurrent load, and target latency; the ehb sources provide none of those parameters. Measure the pilot workload and test a suitable configuration before buying permanent hardware.

Knowledge access must inherit the user's permissions. A customer identifier in a question is not permission to reveal an internal service note. Set dialogue retention limits, remove personal data from the test set, and log document revisions; otherwise, an answer from yesterday is hard to explain after a new release.

Where automation should stop

The assistant is well suited to repetitive questions with a current document and an unambiguous conclusion. It should not independently approve unusual compatibility, promise warranty coverage, or interpret a disputed drawing. Send those requests to an engineer along with retrieved passages. That reduces search time while leaving the decision with a person.

Multilingual support also needs separate testing. A translated technical term can change the meaning of a tolerance or operating mode. Include questions in customers' languages in the test set; an expert should assess preservation of product numbers, units, negations, and restrictions, not merely fluency. “Sounds confident” is a poor metric for wiring instructions.

For an external channel, guard against requests that try to make the model ignore documents or enumerate restricted material. Any high-consequence answer should cite its source or pass to a person. If the documentation is absent, a valid pilot outcome is to conclude that the knowledge base needs fixing first.

Economics without an invented percentage

No public figures are available for ehb electronics, so an estimate for a Russian company can only be illustrative. Assume 300 technical questions per month. If, after validation, the assistant resolves 100 without a follow-up and saves an operator an average of six minutes on each, that frees ten hours per month. This is neither profit nor an ehb result: configuration, document preparation, hardware or API fees, quality checks, and maintenance still have to be counted.

A more honest pilot formula compares the cost per request before and after deployment, including errors and escalations. Also track the share of answers citing a current document, refusals, and handoffs to specialists. If the assistant reduces customer waiting but increases engineer time spent correcting hallucinations, the economic effect can be negative.

A two-week next step

Choose one product line and 50–100 anonymized real questions. Gather current manuals and assign an owner to each version. Ask engineers to answer from the documents first, creating a reference set that includes acceptable refusals. Then compare the assistant with that reference: correctness, citation accuracy, access compliance, and response time. Test an obsolete manual and a question the knowledge base cannot answer separately.

Put the assistant on the public site only after a quality threshold agreed by the support manager and an engineer. Keep a clear handoff to a person and review errors daily at first. The ehb case suggests where practical value lies: not in “replacing the expert,” but in turning scattered manuals into an accessible, verifiable support channel.