Your transaction data already contains the next design-in. The challenge lies in extracting it.

The portfolios that sales teams in the electronics industry work with are vast and complex – tens or hundreds of thousands of orderable part numbers are not uncommon for a design-in distributor or manufacturer. The obvious conclusion is not long in coming: no sales engineer, however experienced, can keep a catalogue of this scale in their head.

However, that was never the real problem. Components generate revenue – but rarely in isolation. A design requires more than just the single component that the customer happened to ask for. And the sockets you don't fill won't remain empty; a competitor will fill them. The revenue that distinguishes a successful design-in from a mediocre project success therefore lies in the relationships between the components: which part is typically used together with which other one, in what type of application, and within what customer background? These relationships are the real asset, and they multiply significantly faster than the catalogue itself. They are not missing – they are buried. Every single one is already in your own enterprise data, spread across thousands of completed successful transactions, design registrations, and projects. But none of this is worth anything unless it is extracted and presented to someone who can act on it. Today, in most cases, this retrieval does not take place systematically. Anyone who goes through opportunity by opportunity in CRM or ERP is always looking only at the individual case – whereas the pattern only becomes visible in the aggregate. And this is exactly what such an individual view cannot show.

Utilising what the systems already contain

Making these aggregated patterns usable is not a reporting task. The process must run continuously across the entire database and deliver its insights to sales at the exact moment they are working – this is precisely the task of a recommendation engine. A purpose-built recommendation for the electronic industry therefore does not start with new data, but with the data sets already available. It does not replace CRM or ERP; it sits on top as a layer and reads what is already there: which customers bought which components, in which projects, for which applications, and with what result? Nothing new needs to be collected: the transactional record that sales teams have been maintaining for years – often with a certain amount of disappointment about how little benefit they get back for it – already contains everything about what was designed in and what came of it. This history turns out to be the truly valuable raw material.

What this data delivers are patterns: combinations that repeatedly emerge in successful designs. And because the engine acts as an intelligence layer rather than a static report, it can incorporate a second type of expert knowledge alongside the buried insights. Reference designs already contain deliberate engineering decisions about which components belong together. Product marketing, in turn, knows which cross-sell opportunities carry strategic weight – an assessment that is particularly important for New Product Introductions (NPIs) where no transaction history yet exists. Today, this knowledge usually only reaches a few people in a training session and then frequently fizzles out. Delivered via the same layer, it reaches every sales engineer – in the exact context in which it is needed: attached directly to a real-world opportunity, instead of sitting in a folder.

“What sells together?” is the wrong question

All of this is worthless if the question asked of the data is too generic. The obvious question – which products sell together – averages behaviour across a customer base that does not act uniformly, and delivers recommendations that may be technically correct but are commercially less meaningful.

The question must carry more context: not just which products occur together, but in which application and in which customer context. A combination that is strong in industrial drives may be completely irrelevant in automotive body electronics. And a pattern that applies to Tier 1 OEMs with their own design capabilities may not apply to smaller design houses that rely heavily on distribution support. Segmenting customers according to how they actually buy – rather than by sales geography, which usually dictates the account structure – turns a merely interesting recommendation into an actionable insight.

Identifying these groups has a second, less obvious benefit: it also shows which customers do not belong to any of these groups. Some accounts simply buy completely differently from the rest – due to a legacy platform, a single dominant end product, or a procurement policy that nobody else shares. Trying to force these customers into the next best group not only generates poor recommendations for them, but also subtly degrades the recommendations for all other accounts in that group. Leaving them out is a deliberate decision, not an omission.

Why exclusion is just as important as detection

The same instinct – knowing what to leave out – must reach a level deeper, because the most convincing false patterns are based on completely real transactions. Suppose a single customer places a very large order for an unusually wide range of components. Measured purely on volume, this one deal can outweigh hundreds of normal orders and look like a strong, proven combination. However, it is nothing of the sort – it occurred exactly once, at a single account, for reasons that applied only to that account. If left unchecked, it will be served up as a supposedly safe recommendation across an entire segment. However, relevance is the only currency here: a recommendation that does not fit the customer at hand is worse than no recommendation at all – because it costs the sales rep time and the recommendation engine its credibility. The first sales manager to see this will immediately draw the logical conclusion: this engine does not understand my market.

The remedy is less of a technology than a basic principle: evidence is counted by breadth, not by weight. A combination only deserves the status of a pattern when it is repeated independently across a sufficient number of different customers, so that coincidence is ruled out as an explanation. No single deal – no matter how large – can justify that on its own.

This hurdle applies to what is derived from history. Knowledge that comes in as a deliberate intent specification – such as a reference design or a cross-sell recommendation defined by product marketing – does not have to clear this hurdle, as this was never a statistical claim in the first place. It possesses a different form of authority and reaches the sales rep flagged accordingly. It is precisely this distinction that makes it possible to recommend newly introduced components that do not have a project history. This is why these two types of knowledge are kept visibly separate from one another, rather than being mixed into a single score.

The same restraint also determines what reaches the output in the first place: components that are close to End-of-Life (EOL) or subject to restrictions for certain markets are held back before a sales rep is recommended them. None of this is spectacular, and it is rarely discussed – but the controls that prevent noise from being elevated to a signal are worth at least as much as the detection itself.

Where the recommendation needs to land

Credibility also depends on where the recommendation appears. A ranking list in a monthly report leaves the translation work to the sales rep; a recommendation linked directly to a specific opportunity and mapped to the concrete project does this work for them. This placement also ensures that it remains live: if an opportunity is initially categorised under the wrong application – a frequently required correction during design-in – the recommendations change the moment the mapping is corrected, because the application was part of the derivation. The output follows the current status of the opportunity, not its status during the last batch job run.

In this setting, the engine performs a very specific task: it identifies gaps. What is conspicuously missing – based on what this customer has already specified in this application with this profile – compared to comparable, successfully completed designs? FSEs and FAEs then do what only they can: they weigh this against everything that is not in the data – the customer's roadmap, a competitor's placement, a qualification hurdle, a conversation from the previous week. The system suggests, the human decides. Any workflow that reverses this sequence will be bypassed by sales in a very short space of time.

What the human decides becomes the next answer

And because the human decides, the decision itself is information. A recommendation that is accepted and leads to a new design registration flows back into the model as evidence: rules that continue to prove themselves are strengthened; rules that are consistently ignored become visible as such. This is the difference between a recommendation engine and a one-off analysis: quality is no longer a matter of opinion, but becomes measurable and thus improvable.

The effect also accumulates. The latest State of Sales study of over 4,000 sales professionals in 22 countries puts the proportion of a rep's working time actually spent selling at 40%; the rest is spent on data entry, prospecting, and internal processes. There are two ways to respond to this figure – and this approach serves both. A large part of the remaining 60% consists of manual research: searching for what a customer might need next, reconstructing what comparable accounts have designed in, and manually creating a shortlist. Work of this kind does not need to be done by humans at all. If sales is relieved of this, the 40% itself shifts – towards customer meetings instead of more administration. In addition, the return on the hours already spent selling increases, as these conversations are now based on the collective experience of the entire organisation – and not just on what a single person happens to remember.

The data is already there and has accumulated over years. The question at management level is not whether it contains commercially usable patterns – it does. The question is whether anything in the current tech stack is capable of extracting them and providing them to the person who owns the customer relationship – while there is still time to act.