Internal AI search assistant

The client

A Hungarian contracting company that works project by project: from first enquiry through technical design and permitting to construction and handover, every project runs for months, across several colleagues and several stages. Close to five thousand such projects had accumulated over the years.

This system was not built as an external engagement — it was built from the inside, as the company's process manager. The company name is not published.

The starting point

Project data lived in a spreadsheet of several thousand rows and 149 columns. Formally, everything was in there; practically, almost nothing could be got out.
Those who knew where to look still scrolled and filtered for minutes. Those who did not asked a colleague — so one person's question cost two people's time.
More involved questions — "which projects in that region were contracted after March" — could only be answered by someone willing to build a formula or a pivot table.
Client and partner names had been entered with typos, without accents, or abbreviated. Plain search often returned nothing even though the data was there.
Construction status was tracked in a separate spreadsheet, so the full picture always had to be assembled from two places.

The solution

An internal assistant that answers questions in plain language — in a chat, in the browser, behind the company's own login.

Two separate search tools, and the assistant decides which to use. A "show me something like this" question gets a meaning-based search; a "filter for this" question gets an exact, structured query. That split is the heart of the system — pure meaning-based search fails on filtering questions, because those are conditions, not similarity.
Typo-tolerant name search — accents, hyphens, abbreviations and fragments all still find the record. In practice this produced the most successful searches, because names had been entered many different ways over the years.
Two sources, one answer — the project register and the construction status are linked, so the same thing does not have to be looked up twice.
Data refreshed every fifteen minutes — only rows that actually changed are reprocessed, which keeps the refresh cheap and fast.
The assistant knows how fresh the data is — you can ask when the last refresh ran, instead of guessing.
Read-only by design. Queries are technically constrained: a single read statement, with a time limit and a row limit. The assistant cannot modify or delete data, even if asked to.
Login with the company's own account — the interface sits behind a company email address, with no separate password and no separate user management.

Outcome

Searching became asking. Nobody needs to know which column holds the data, and nobody needs to write a formula for it. People who used to ask a colleague now ask the assistant — and the colleague's time stays theirs.

The data never leaves the company. The language model that interprets the text runs on the company's own server, not at an external service. Client names, addresses and project data are therefore never passed to a third party. This was not bolted on afterwards; it was the starting design constraint — and it is what made running on real client data acceptable at all.

Answers can be checked. The assistant answers by pointing at specific projects rather than in generalities, so every answer can be traced back to the register.

Where else this works

The solution is not built on the industry. It is built on a situation: a company's most important data sits in a spreadsheet nobody can see through any more. That happens almost everywhere.

In trade — product and supplier registers running to thousands of rows.
In manufacturing — production lines, order books, machine data.
In services — client and contract records where the detail accumulated over years.
In any company where colleagues ask each other because it is faster than looking it up.

The requirement is not size but structure: a maintained, reasonably orderly register. If the data is messy, that has to be fixed first — the assistant finds what exists, it does not repair what is missing.

Operation

The system runs on a dedicated server in the EU. The data refresh and the search service run independently, so an outage in one does not take the other with it. Questions and answers are logged, with a limited retention period.

This case study is based on a real system, anonymised. Time savings were not measured, so no figure is claimed for them.