Przejdź do treści głównej Skip to main content
Powrot do publikacji Back to writings
Article Published

The catalogue starts with the product. The customer starts with the problem.

Technical sales keeps producing good explanations of applications. A practitioner's view on making them last, for colleagues, customers and people researching an application before they contact a supplier.

A pyramid of six cubes. Three yellow cubes at the base hold existing knowledge: Knowledge, Applications and Expertise. Two blue cubes, Explanation and Review, rest on them and support one blue cube at the top, Reuse, labelled Sales, Training and Web.A pyramid of six cubes. Three yellow cubes at the base hold existing knowledge: Knowledge, Applications and Expertise. Two blue cubes, Explanation and Review, rest on them and support one blue cube at the top, Reuse, labelled Sales, Training and Web.

The catalogue starts with the product. The customer starts with the problem.

I often think about how much time and experience goes into explaining technical applications, and how little of that effort sometimes survives the conversation.

A customer receives a quotation for pull-wire switches for several conveyor sections. Some devices are designed for one-sided operation, others for two-sided operation. The obvious question follows: why the mix? Why not use the same version throughout?

I have answered that kind of question many times. The catalogue gives the specifications and the datasheets establish the limits, but they cannot, on their own, explain the reasoning behind every application-specific choice. On long conveyor runs, temperature-related changes in wire length can make the distinction between these two configurations particularly relevant. The right choice still depends on the conveyor layout, operating conditions and other application requirements, all of which need to be properly assessed.

That recurring question points to something broader. What if we could turn the explanations developed in everyday sales work into something reusable? Focused, technically sound material that helps colleagues and customers understand an application, explore the reasoning and have a more informed discussion.

The information exists. The question arrives differently.

Industrial manufacturers already produce substantial technical documentation: product pages, datasheets, industry guides, application notes and training material. Much of it is excellent. The challenge is that the structure of a portfolio and the questions customers bring to a conversation are rarely identical.

A manufacturer groups information by product family, technology or industry. The person looking for a solution begins with an application, an operating condition or a decision they need to make. Related switching technologies may be considered in a manufacturing plant, an underground mine or an outdoor bulk-material conveyor system, but each environment brings different requirements. Understanding those differences is essential before discussing which products might be suitable.

Application notes are hardly new. Manufacturers have been writing them for decades. What interests me is the earlier moment, when a useful question surfaces repeatedly in sales conversations, discussions with distributors or technical support exchanges. It may be particularly relevant in one market, even if it never becomes a priority for the manufacturer’s central communication.

That is an opportunity to connect existing authoritative product information with the precise questions people actually ask.

The explanation you keep giving

The pattern is surprisingly familiar. You explain a technical distinction to one customer. A few weeks later, the same question comes up in another conversation. Then a distributor needs to explain that distinction to their own customer.

Of course, some questions are already covered well by available documents. Others are so specific that a general explanation would be misleading. The ones worth preserving tend to come up repeatedly, require meaningful judgement and contain reasoning that remains useful across different situations.

When I explain the same technical distinction repeatedly, I see knowledge worth preserving.

Returning to the pull-wire example, a reusable explanation wouldn’t tell someone which switch to choose without knowing the application. Instead, it would explain why the specifications alone aren’t enough, what operating conditions need to be considered and where to find the official technical information needed to make an informed decision.

I see the demand for this kind of context in training too. In conversations with distributors and colleagues, the most useful discussions often move quickly beyond product features. People want recognisable applications and practical explanations they can carry into conversations with end customers. They need to know what the technology means in the setting where it will be used.

Official product documentation and a recurring application question both feed a reviewed explanation, linked to product data, which leads to clearer technical conversations. Official product documentation and a recurring application question both feed a reviewed explanation, linked to product data, which leads to clearer technical conversations.
A recurring question gives existing documentation a focus. The explanation stays linked to the official product data it draws on.
Mermaid source
flowchart TB
    A[Official product documentation] --> C[Reviewed explanation, linked to product data]
    B[Recurring application question] --> C
    C --> D[Clearer technical conversations]

Learning the application is only half the job

This became particularly clear to me recently when I helped a new sales engineer become familiar with our product portfolio.

A datasheet provides the technical specifications of a device. Product training adds the operating principles and limitations. But customer conversations require another skill: deciding where to begin, which distinctions deserve attention, how to explain alternatives in clear language and when to bring a specialist into the discussion.

Knowing a product is one thing. Knowing how to explain it to a customer is another.

That second skill develops through experience, especially through conversations with customers and more experienced colleagues. Having recurring application explanations already structured, checked and ready to discuss could make that learning easier. A new colleague could learn both the technical reasoning and a useful way of communicating it, then build on that foundation through their own experience.

I would use those explanations myself. Even when I know an application well, the useful fragments may be spread across old emails, templates, catalogue links and previous documents. Reconstructing that explanation for another customer takes time. And a long email often loses its context when forwarded to an engineer, purchasing colleague or manager.

Preparing a really good explanation still takes time and effort. That is precisely why I want its value to last. Once the reasoning has been developed, structured and reviewed, it should be available for the next conversation without having to repeat all that work.

Let good communication become reusable work

There is a practical benefit on the customer side as well. Customers are busy. A broad introduction to a manufacturer’s entire portfolio has its place, but an explanation focused on a relevant application is often more useful to them.

When I research a potential customer, I try to understand the activities and applications that may be relevant. A prepared explanation gives me a way to introduce a specific, useful topic without assuming I already know what the customer needs. The same material can help answer an incoming question, support a follow-up, accompany a quotation or prepare a distributor for a customer discussion.

The technical reasoning can remain the same while the presentation adapts to the audience. A good structure helps maintain accurate product references, clear wording and a recognisable visual identity without turning everything into generic sales material. This matters to customers too: McKinsey’s 2026 Global B2B Pulse Survey found that inconsistent information across teams was the leading reason B2B buyers cited for switching suppliers.

The effort invested in one good explanation should keep creating value in the next conversation.

This requires discipline. Technical claims need reliable sources and appropriate review, especially in safety-related applications. The material also needs to stay current as products and requirements change. And confidential customer applications cannot simply become public examples by removing names. What we can reuse are explanations deliberately prepared and reviewed for their intended audience and purpose.

If this becomes a regular part of everyday work, the result is more than a folder of PDFs. It is a growing collection of practical application knowledge, including examples of how to communicate it well.

A new way for useful explanations to reach customers

Until recently, I mostly thought about these materials as something a salesperson would send. That is still valuable: I know the customer’s question, select the relevant explanation and use it to support the conversation.

But the way customers research possible solutions is changing. Someone can now use an AI assistant to explore different approaches, compare terminology and follow references before speaking to a supplier. Instead of searching for a particular product, they can describe their application and explore which technologies might be relevant.

The 2026 State of Marketing to Engineers report from GlobalSpec and TREW Marketing illustrates this change. In 2025, 42% of respondents said they never used generative AI when evaluating vendors or researching work-related purchases. By 2026, that figure had fallen to 31%. Yet traditional sources remain important: when asked where they routinely research work-related purchases, 76% selected online technical publications, 74% supplier websites and 21% generative AI platforms. Even among those who encountered AI-generated search summaries, many continued to the underlying search results.

I find the combination more interesting than any single percentage. AI can help someone begin exploring an unfamiliar application, but reliable technical information remains essential when evaluating possible solutions. This is particularly important with industrial equipment, where details and operating conditions matter. The same survey also found that engineering experts working for suppliers were the most trusted authors of technical content, reinforcing the value of expertise behind these explanations.

Now imagine taking an explanation originally prepared for a recurring sales question, reviewing it with the people responsible for the technical information and publishing it as a clear, accessible web page. Someone researching a similar application might discover it through conventional search or an AI-assisted search system. They could explore the reasoning and follow references to official product documentation. There is no guarantee that an AI system will cite or recommend the page, but making this knowledge publicly available creates another opportunity for it to reach someone who needs it.

A useful explanation can serve the customer I know today, and potentially reach the one I have never met.

One reviewed explanation leads to sales material sent as a PDF or link, to internal learning material and, only after a separate public approval, to a public web page that may be found through search or AI tools. One reviewed explanation leads to sales material sent as a PDF or link, to internal learning material and, only after a separate public approval, to a public web page that may be found through search or AI tools.
Sales and learning material can follow directly from the review. A public page needs its own approval, and being found through search or AI is possible, not promised.
Mermaid source
flowchart TB
    E[One reviewed explanation] --> S[Sales: PDF or link]
    E --> L[Internal learning]
    E --> G{Separate public approval}
    G --> P[Public web page]
    P -.-> Q[May be found by search or AI tools]

Don’t let the explanation disappear

I’ve been exploring this approach while building Scenario Spotlight, a tool for creating focused, application-oriented documents from prepared scenarios and relevant technical context. The experience has reinforced something I recognise from sales: the document itself is only the visible result. The real work lies in deciding what is worth explaining, how to communicate it clearly and how to preserve the technical reasoning.

I believe there is real value in making this work build on itself. Start with a few questions that keep returning. Check whether existing material already answers them. Prepare a good explanation where there is a genuine gap, review it appropriately and put it to use. Then improve it when the next conversation reveals a clearer way to communicate the point.

One useful explanation becomes two, then a small collection. A newer colleague has useful material to learn from. An experienced colleague spends less time putting familiar explanations together. Customers receive clearer information that can be shared beyond the original conversation. And selected public pages can remain accessible even when nobody is actively sending them.

We already invest time and draw on experience to explain difficult technical questions. I think we should make more of that effort last.

The result I want is simple: better-prepared people on both sides of the conversation, able to spend more time on the application-specific questions that really matter.