What actually happened in the case

On 24 February 2026, the European Digital Innovation Hubs network published the expert-hub.li case. The customer is identified as GB Marketing & Solutions GmbH, a Liechtenstein SME specialising in digital marketing. The objective went beyond a conventional chatbot: the company wanted a marketplace where a business or private client could describe a need, find a suitable specialist and move all the way to a delivered and paid service.

The published solution includes expert profiles, defined service offers, chat, meeting scheduling, document exchange, video meetings, invoicing and payment. AI supports matching a customer request to an expert. The case also mentions KI-Lie, an assistant that provides initial guidance on Liechtenstein topics and directs customers to relevant advisers.

The impact must not be overstated. The case authors explicitly say that measurable data will be provided after the first six months of operation, although a statistics system is already running. The available evidence therefore confirms the scope of the solution and the launch of a new business model, but not revenue growth, shorter handling time or recommendation quality.

That distinction is the practical lesson for Russian SMEs. AI matching is one narrow module. Value appears when a controlled workflow surrounds it: the request is captured, requirements are clarified, a candidate is found, a meeting is scheduled, documents are shared, delivery is confirmed, an invoice is issued and the outcome becomes measurable.

Why an “expert-matching chatbot” is too narrow

Connecting a language model to a list of specialists may produce fluent profile summaries, but it does not guarantee that an expert serves the required industry, is available by the deadline, is qualified to deliver the service or accepts the stated budget. The risk becomes greater if the model is allowed to promise a price, reserve time or initiate payment without enforcing business rules.

A consulting request has at least two layers. The first is semantic: what the customer needs, where the problem occurred and which capabilities are relevant. The second is operational: region, language, deadline, delivery format, price, availability, legal restrictions and the expert's consent to accept the request.

AI is useful for the first layer. It can normalise free text, identify intent, retrieve related profiles and explain a match. The second layer belongs to conventional filters and transactional software. Availability comes from a calendar, pricing from the service catalogue, access from policy and payment status from the accounting or payment system.

This is why a viable platform resembles a pipeline with independent controls rather than one large chat interface.

An architecture for local matching

A five-stage design is practical for a small business.

1. **Structured intake.** The customer describes the problem in natural language, while the form separately collects hard constraints: industry, region, language, deadline, format and budget range. The original request is stored with consent and provenance.
2. **Request normalisation.** A small local LLM or classifier converts the description into intents, required capabilities and clarification questions. It does not make the final decision or invent missing constraints.
3. **Candidate retrieval.** The system combines full-text search with vector similarity over service descriptions, cases and capabilities. Metadata removes candidates with the wrong language, region, availability or budget.
4. **Ranking and explanation.** A reranker scores the shortlist. The user sees several options with concrete reasons, such as matching expertise, relevant experience and availability. A person selects an expert or requests clarification.
5. **Deterministic execution.** Calendar booking, CRM opportunity creation, document access, invoicing and payment are handled through ordinary APIs with role checks, idempotency and an action log.

An on-premises or private deployment is appropriate when requests contain trade secrets, personal data, internal documents or sensitive customer information. The model, profile index, recommendation log and tool gateway can remain inside the protected environment. Only operations already delegated to external services, such as calendars or acquiring, need to leave it, and each outbound integration should expose the minimum required fields.

A large model is not mandatory. For a catalogue containing hundreds or a few thousand experts, a clean taxonomy, complete metadata and a compact reranker usually matter more than expensive generation. The LLM should translate between free-form language and catalogue structure, not own the transaction.

Data and integrations

Expert profiles must be machine-readable. A marketing paragraph is insufficient. Useful fields include:

  • services and capabilities mapped to a shared taxonomy;
  • industries and problem types served;
  • language, region, meeting format and availability;
  • price range and pricing rules;
  • verified qualifications and restrictions;
  • project examples that do not disclose client-confidential data;
  • last-updated date and profile owner.

Training a custom ranking model requires observable outcomes rather than simple likes: which candidates were shown, who was selected, whether the meeting took place, whether the request was qualified, whether the service was completed and whether a complaint followed. These events share one request identifier, while personal data access remains separated from the analytics dataset.

The minimum integration set is a CRM or request register, service catalogue, calendar, secure document store, notifications and payment records. Models should not connect to these systems directly. A tool gateway validates input schemas, user rights, allowed state transitions and duplicate operations.

Where the system fails

The primary risk is persuasive irrelevance. A profile may share vocabulary with the request but lack the required experience. The interface should therefore show why each recommendation was made and identify the source of every claim. Users need a way to reject a candidate and record a reason.

The second risk is stale information. An expert may have changed specialisation, become unavailable or stopped offering a service while an old profile continues to rank highly. Profiles need expiry periods, renewal reminders and a ranking penalty when confirmation is overdue.

The third risk is ranking bias. If training uses only past clicks, popular specialists receive even more exposure and new specialists become invisible. Catalogue coverage, new-profile exposure and reasons for human overrides should be monitored separately.

The fourth risk is instruction injection through profile text or uploaded documents. Such content is data, not a command. The model must not receive payment credentials, change a user's role or call arbitrary URLs.

NIST AI RMF provides a useful management frame: roles and responsibilities for oversight should be defined in advance, and human intervention outcomes should be recorded. A generic “human checked it” step is not a control unless the organisation specifies who reviews a match, which criteria apply and what happens after rejection.

Economics: measure a completed service

The expert-hub.li case does not yet provide confirmed performance metrics, so another company should not budget on assumed sales growth. It should first calculate the current handling cost and a modelled opportunity.

Suppose a business receives 300 requests per month. An employee spends an average of 12 minutes clarifying and routing each request, and the fully loaded labour cost is RUB 900 per hour. If the system removes half of that effort, the modelled saving is RUB 27,000 per month: `300 × 0.2 hours × RUB 900 × 50%`.

This is not a forecast; it is an example with explicit assumptions. Catalogue preparation, integration, maintenance, recommendation review and matching errors must be deducted. Any conversion uplift belongs in the business case only after a controlled observation period.

The main metric is cost per service completed and accepted by the customer. Supporting metrics include:

  • time to the first qualified response;
  • share of requests where a suitable candidate appears in the top three;
  • recommendations accepted without a separate manual search;
  • request-to-meeting and meeting-to-completion conversion;
  • cancellations, reassignments and complaints;
  • manual review and support cost;
  • share of complete and current profiles.

A low-cost pilot

A pilot does not need a full marketplace with video meetings and payments. One process, 30–100 expert profiles and 100–200 anonymised historical requests are enough to test the core hypothesis.

In week one, define the service taxonomy and mandatory fields. Experts then confirm their profiles. On the historical set, the system should return three candidates while employees independently judge their suitability. A shadow phase follows: the algorithm generates a shortlist, but customers still receive human-curated recommendations.

Production use begins only after the agreed quality threshold and edge-case review are passed. The first automated action can be a draft CRM record. Booking, document sharing and invoicing should be connected one at a time, each with logging and cancellation support.

That sequence transfers the central expert-hub.li lesson to any SME: do not begin with a “universal AI adviser.” Define the service, data and workflow states first. Then introduce AI precisely where free-form language makes it difficult to find the right person.