What happened at Intrim

Australian building-products manufacturer Intrim Group launched a website assistant for product selection and installer discovery. Its developer, Airgentic, describes two connected journeys: a visitor states a need in ordinary language and receives suitable mouldings, trims, and style options; when needed, the visitor can look for a nearby installer. This is not an example of a fully autonomous sale. The customer compares options and decides, while the company remains responsible for catalog accuracy and its partner directory.

According to Airgentic's announcement dated March 12, 2026, the new search replaced Intrim's previous Algolia implementation. A separate “Find an Installer” agent queries spatial data from WP Store Locator in the WordPress environment and displays nearby professionals in Google Maps. Elastic's case study describes Airgentic's search layer: one index and hybrid ranking combine lexical and semantic retrieval, while a generative model constructs answers from retrieved content.

This is a documented overseas deployment, not proof of universal return on investment. Elastic reports a customer-supplied estimate that about 94% of 3,400 conversations over two months were “fully answered.” The public material does not disclose the measurement method, confirmed order share, or costs. That number must not be treated as independent model accuracy or sales growth.

Why a basic chatbot is not enough

A product catalog receives two very different query types. One buyer enters an exact model code such as CM25; another describes a “narrow profile for a neat wall-to-ceiling transition.” A semantic model can match descriptions by meaning, but an alphanumeric identifier may carry no useful semantic meaning. Lexical search better protects an exact match. Combining signals without tuning can confidently surface a similar but incorrect product.

Elastic's Intrim account explicitly identifies model-code queries as a problem. Airgentic customizes tokenization for product codes and gives more weight to keyword search when a query resembles a model number. Descriptive queries can benefit from both signals. Elastic's Linear retriever documentation explains how scores from child retrievers can be normalized and weighted. The exact weights of one deployment should never be copied blindly; they need evaluation against a company's own query set.

Independent context comes from Walmart researchers' paper on product retrieval. They likewise combine a conventional inverted index with embedding-based retrieval for difficult shopping queries. This supports hybrid retrieval as an engineering option, but does not validate Intrim's reported outcomes or imply that a small manufacturer needs the architecture of a large marketplace.

How a smaller business can build the same journey

Start with a clean catalog, not a language model. Each product needs a stable SKU, name, spelling variants, category, dimensions, material, compatibility, availability, sales region, current price, and update time. Manuals, specifications, and FAQs can be indexed separately while retaining document URLs and versions. If a dimension or price is missing, the assistant should disclose the gap rather than guess.

A practical pipeline is:

  • normalize the query while preserving the original SKU characters;
  • check exact-code matching and structured filters first when the query resembles a product identifier;
  • combine lexical and vector results for descriptive queries;
  • filter out unsuitable materials, dimensions, availability, or regions;
  • give the model only a small set of retrieved cards and documents with source links;
  • present a few options with their differences and hand exceptional cases to a person.

Installer search is a separate integration, not an extension of linguistic guesswork. The directory needs current coordinates or service areas, specialisms, partner status, and consent to publish contact details. A geospatial service or database computes distance; the model merely helps clarify the location and present the result. Intrim uses WordPress WP Store Locator data with Google Maps display. A Russian business may choose different mapping services and its own contractor register depending on availability, contracts, and data requirements.

When a local deployment makes sense

The Airgentic case is not evidence of a wholly local AI stack: Elastic's publication mentions Microsoft Azure cloud infrastructure. A company with private price lists, dealer terms, or personal customer data could adapt the pattern by keeping its search index and model inside a controlled environment, exposing them to the public website through a restricted API. That is an architecture option for a different deployment, not a feature demonstrated by Intrim.

Even a local implementation needs access boundaries. Public visitors should see only published prices and documents. Staff may access dealer inventory after authentication. Queries and answers should be logged without unnecessary personal data, and the logs should support error reviews. For a simple public catalog, a local model may cost more than a managed service; the decision should follow workload and risk estimates rather than a slogan about running everything on one's own server.

Economics and quality measures

The major expense is often not model calls but catalog preparation, price and inventory synchronization, SKU correction, and maintaining an installer directory. Search indexing, document storage, embedding computation, answer generation, monitoring, and human review of questionable recommendations add further costs. A common search-and-answer layer may remove duplicate indexing, but actual savings require vendor invoices and measured team effort.

A pilot can use 100–200 anonymized real queries: exact SKUs, free-form descriptions, mixed requests, missing products, and installer questions. Measure whether the correct product appears near the top, the share of answers with verifiable links, wrong recommendations, correct handoffs to staff, latency, and cost per useful conversation. Track conversion to an inquiry separately: “answered” does not mean “ordered.”

For a modest assortment, begin with reliable exact search and filters. Add a semantic layer if real queries expose a vocabulary mismatch. Add a generated answer later, after retrieval has proved trustworthy. The experiment can then stop at a useful intermediate result instead of paying for agent complexity too early.

A two-week next step

In week one, export the catalog and twenty common support requests, fix the essential attributes, and mark SKU-based queries. In week two, compare existing search with a simple hybrid prototype on a labeled set. Allow generation only from retrieved product cards, show product links, and provide a handoff button to a human adviser. If the prototype confuses codes, prices, or stock status, do not release it to buyers: repair the data and filtering rules first.

The practical lesson from Intrim is not that every website needs an “AI salesperson.” It is that a useful assistant rests on a trustworthy catalog, exact identifier matching, carefully combined semantic retrieval, and a verifiable integration with the buyer's real next step.