Customers Don’t Search for Article Numbers

“IA0032, IFT200, Pi2795” – anyone searching like this already knows what they need. The more challenging and more common scenario looks different: someone has a task to solve on a machine or system and has no idea which of more than 14,000 products can solve it.

Traditional keyword search relies on exactly what these customers lack: product knowledge. It matches strings against catalog fields. When someone describes their environment, medium, and goal instead, they either get no results or a list that appears to be sorted by relevance but doesn’t enable them to make a decision. For companies, this has tangible business consequences: users drop off and return to Google. The groups most affected are also the most valuable ones:

• New customers without portfolio knowledge

• Customers considering a switch who are just starting to explore the product range

  
  

What would lead to a personal consultation in a traditional sales setting often ends online with the user leaving the site.

This is exactly where the Application Assistant (Product Advisor) comes in at ifm. It provides an additional entry point alongside the traditional search — customers who know a part number can continue searching as usual. Those who have a problem can simply describe it. A real-world query from the production environment looks like this:

“How can I – in a dusty environment of a parcel logistics centre – reliably register and count the number of parcels and packages on a roller conveyor?”

No product name, no technical specification — just the environment, application and objective. In this example, the Product Advisor recommends 3D sensors from the O3D series and deliberately presents two options side by side: the more compact O3D354 with a wider field of view and the O3D314 with a stainless-steel housing for maximum robustness. It also provides a rationale that would not typically be found in a product datasheet: infrared ToF technology is not significantly affected by dust particles, unlike conventional optical sensors.

The second round is even more interesting. The follow-up comes in the way people actually type — including typos and without technical terminology:

“I need a more compact version but with a wider field of view, since I want to register and count bigger parcels and pallets.”

The Product Advisor retains the context, selects the O3D354 and explains its recommendation based on the criteria that now matter: a compact size of 72 × 65 × 76.9 mm, a 60° × 45° field of view, IP65 protection, a 25 Hz refresh rate, a working range of 300 to 8,000 mm, and PROFINET or EtherNet/IP connectivity. It also identifies comparable real-world applications, such as completeness monitoring and depalletizing.

And then it does something a search engine cannot: it asks a follow-up question:

“Do you already have an approximate mounting distance and conveyor width, so I can provide more details on the exact positioning?”

That is the difference between finding and advising. All mentioned products are linked directly alongside the recommendation — so the decision leads to the next step in a single click rather than taking the customer away from the website.

These dialogues may look straightforward at first glance. The real challenge, however, lay behind the scenes – and that is one of the key takeaways from the project. Setting up a language model with a chat interface is quick. Building a robust application required significantly more:

• Bringing Data Sources Together
  Product data, application reports, and CMS content were stored in separate systems. To provide a reliable recommendation, the assistant needs all three at once: the specification, the documented use case, and the explanatory content layer.

• Answer Quality, Not Plausibility
  A recommendation must be traceable to approved sources. The most difficult scenario in production is not an incorrect answer – it is an incorrect answer that sounds convincing.

• Clear Boundaries for AI-Powered Advice
  When it comes to technical product selection, advice must stop where binding commitments begin. The assistant needs to know when to provide guidance and when to hand the user over to an expert.

• Monitoring and Automated Testing
  Models change, and product data changes. Without repeatable testing, no one knows whether the quality of an answer from last week still holds today.

• Feedback as Part of Operations
  Each answer includes a rating option and a free-text feedback field. These signals are not an afterthought; they provide the data basis for further development and show how the assistant can be improved and which data sources may still be missing.

• Clear Responsibilities
  Who maintains the data, who evaluates answers from a technical perspective, and who decides on changes? These are not technical questions, but organizational ones.

  
  

All of this remains invisible to users. Yet these very foundations determine whether an AI application works reliably in day-to-day production.

The Application Assistant (AI Product Advisor) has been in production at ifm since June 2026, initially in three countries, covering a portfolio of more than 14,000 products. The results speak for themselves:

• more than 1,000 sessions in the first week

• around 250 sessions per day

• approximately €0.015 per consultation

  
  

The number of sessions is more meaningful than it may seem at first glance: the assistant is an optional service that complements the existing search experience. Customers therefore use it deliberately because it provides additional value. At the same time, each consultation costs around two cents. The question is therefore less whether the service is worthwhile and more where there is additional demand for advice that we are not yet covering.

What really matters: The assistant is being adopted and actively used. Not only customers use it, but also internal teams in service, product management, and sales. There is also strong interest from local country organizations: for the next rollout, they too want to make the service available to their potential customers.

The project offers three key lessons:

1. Start with the User Problem, Not the Technology
   The use case was clearly defined from a business perspective before any models were discussed. This may sound obvious, but it is one of the most common mistakes in AI initiatives.

2. Data Integration Is an Effort – and a Competitive Advantage
   Any company can buy a language model. Connecting product data, documented application experience, and relevant content, however, is company-specific and cannot simply be purchased off the shelf. This is where the real value is created.

3. Think About Operational Readiness from the Start
   Monitoring, quality standards, and clear responsibilities should not be addressed at the end of a project. They need to be considered from the outset. Without these foundations, a pilot may be technically functional, but it will not be reliable or sustainable in production.

   
   

What emerges from this project also creates lasting value: the foundation built for this particular use case is already in place for the next one – integrated data, validated answer quality, and an established operating model. As a result, the second use case is significantly less costly than the first.

The more interesting question is no longer whether an AI use case works, but how companies can make it repeatable: turning a successful case into a capability that can also deliver value in other areas.

The ifm case shows that a good AI application is not created by a powerful model alone. What matters is the interplay of user understanding, data, domain expertise, and a reliable operating model. These foundations can also be applied to other companies and use cases.

Would you like to make your product search smarter and more advisory with AI? The Product Advisor makes complex product portfolios easier to navigate through AI-powered guidance – directly within the existing digital customer journey.