B2B sales of products that need explaining: what really works

Products that need explaining have one thing in common: the customer cannot see their value on the pricing page. SaaS with integrations, cybersecurity solutions, ERP rollouts, technical equipment: they all change a process at the customer, and exactly that change has to be understood before anyone takes responsibility for it. This article sums up what really works in such sales processes, from our own practice.

What “needs explaining” means in sales

A product needs explaining when the buyer cannot judge without advice whether and how it solves their problem. That is not a question of technology alone. A piece of software can be simple and still need explaining, because it replaces an established routine and touches several departments. Conversely a technically complex product can be sold transactionally when the customer knows exactly what they need.

Three characteristics almost always appear together:

• The need has to be worked out. The customer has a problem but often no name for it and no idea what a solution should cost or deliver.
• Several people decide. Department, IT, procurement and management judge the same offer by different criteria.
• The close needs proof. Demos, proofs of concept, security evidence and references replace the claim.

Whoever takes those three seriously sells differently: first understand, then show, then negotiate. Whoever ignores them presents features to people who do not yet know which problem they want to solve.

Discovery is the sale, not its preliminary stage

In transactional selling the first conversation is a qualification: does the customer fit, do they have budget, when will they buy? In sales of products that need explaining the first conversation is the most important part of the whole process. It decides whether a demo will convince later, whether an offer will be understood and whether the internal champion at the customer will have the arguments they need.

A good discovery answers six questions:

1. Situation: how does the customer work today? Which systems, teams and processes are involved?
2. Process: which concrete flow should change, step by step?
3. Pain: what does the current state cost in time, errors, risk or lost revenue? Importantly: the customer puts it into words, not sales.
4. Impact: what changes once the problem is solved, for the department, for the numbers, for the person at the table?
5. Decision: who decides, who reviews, who can block? By which criteria, against which alternatives?
6. Time and budget: is there a trigger with a date? Is budget available or does it have to be requested?

The most common mistake in this phase is impatience. Sales people who love their product want to show it. Customers who invest time want to see something. Both sides push towards the presentation and in doing so lose the basis on which the presentation could have any effect at all. The better answer to “can you show us?” is a short overview and the honest question of what the customer specifically wants to see in the demo.

Product understanding: why scripts fail

Products that need explaining cannot be sold from a script because the conversation is not predictable. The customer asks questions that depend on their process: how does the solution behave when two systems change data at the same time? What happens to legacy records? What does the permission structure look like? Whoever does not understand the product evades. And the customer notices immediately.

Product understanding in sales does not mean being able to answer every technical question yourself. It means understanding the customer process well enough to recognise which questions are relevant and to pass them cleanly to the specialists. It also means saying no early: if the product does not fit, an honest conversation saves both sides months. That honesty is not a sacrifice but the basis for trust. And in long cycles trust is the most important currency.

At FIOXX a structured onboarding on the product stands at the beginning of every engagement in technical sales: what does the product solve, for whom, in which process, against which alternatives? Only then does hands-on work begin.

Stakeholder mapping: four roles, four conversations

An offer that convinces the department can fail with IT. One that convinces IT can fail with procurement. And one that convinces everyone can stall because management sees no priority. Stakeholder mapping means knowing each of those roles, understanding their criteria and addressing them deliberately.

Role	Question	What convinces
Department	How does my daily work change?	Process, time saved, usability
IT	How does this fit into our landscape?	Interfaces, security, operation, standards
Procurement	Is the offer comparable and fair?	Transparent scope of services, clear terms
Management	Is it worth it, and what is the risk?	Business case, references, ability to deliver

The practical mistake is settling for a single point of contact, usually the friendliest one. The friendliest contact is rarely the decision maker. A good sales process asks explicitly about the other roles during discovery and creates occasions to involve them: a short IT session on integration and security, a meeting with management about the business case, a clean scope of services for procurement.

Demos that show the customer process

Most demos fail not because of the software but because of the order. They start at the login, walk through menus and end at the settings. The customer sees a lot and understands little. A demo that comes out of the discovery reverses the order: it starts with the customer’s problem and shows in the first minutes how it is solved, with their terms, their data, their flow.

What has proven itself in practice:

• Agenda and goal at the start. What will be shown, what will not, and what should be decided at the end?
• Core scenario first. The most important use case comes immediately, not after twenty minutes.
• Depth per role. The department sees the flow, IT sees integration and permissions, management sees result and effort, in separate meetings if needed.
• Document open points. Every unanswered question gets an owner and a date.
• One concrete next step. The demo ends with an agreement, not with “get in touch when you are ready”.

A demo is also not a solo. Whoever sells the product moderates; whoever built it answers the detailed questions. That division looks more professional than a sales person improvising at the third technical question. More on that under demo & closing.

Follow-up is part of the sale

Between demo and decision most opportunities are lost, not through a no but through standstill. The customer is busy, the internal champion needs arguments, a stakeholder has concerns nobody hears. A follow-up that consists only of “any news yet?” does not help.

Effective follow-up delivers something every time:

• a summary of what was shown and agreed,
• answers to the open points, with evidence,
• material for the champion who has to convince people internally: numbers from the discovery, arguments per role,
• a proposal for the next step, with a date.

And it happens reliably. That is exactly where daily practice fails: follow-ups depend on memory and the mood of the day. That is why follow-up belongs in the system: as a task with a deadline, as a sequence per conversation type, with a reminder and escalation when a case stalls. What that looks like technically is described under sales automation.

Long cycles need discipline, not pressure

Cycles of three, six or twelve months are normal with products that need explaining. They cannot be shortened by pressure. Discounts with a deadline and artificial urgency damage the trust the close depends on. What actually shortens cycles:

1. Clarifying the decision path early. Whoever knows during discovery which reviews and committees lie ahead can plan for them instead of suffering them.
2. Actively supporting reviews. Security reviews, data protection questions and integration checks are part of the process. Whoever has the documents ready loses no weeks there.
3. A clear trigger. Projects without a date fade away. A trigger such as a system change, a regulatory deadline or a growth target gives the process a frame.
4. A visible pipeline. Every case has a stage with clear criteria, a next step and a date. What is not visible does not get worked on.

The last point connects sales and system: without a CRM that represents stages, tasks and activities properly, a long cycle cannot be steered. What such a system involves is described in the article CRM automation: from enquiry to follow-up.

The most common mistakes

From our experience in hands-on sales of technical products, certain patterns repeat regardless of industry and product:

• Presentation before understanding. The demo comes before the need has been worked out.
• One point of contact. The process depends on one person who does not decide.
• Feature arguments. Sales explains what the product can do instead of what changes for the customer.
• Follow-up from memory. Following up happens when there is time, which means rarely.
• Fear of the no. Unsuitable opportunities get dragged along for months instead of being clarified early.
• No learning. Loss reasons, objections and cycle lengths are not recorded, so the mistakes repeat.

None of these mistakes is a question of talent. They are a question of process. And a process can be built.

Working tool: discovery grid

We fill in this grid in projects after the first conversation. It is deliberately short: if a row stays empty, that is the next research assignment, not a reason to write the offer anyway.

Field	Guiding question	Example with fictitious data
Trigger	Why now and not in a year?	Certification audit in the second quarter
Current flow	How is it solved today?	Spreadsheet plus a weekly meeting, two people
Impact	What does the current flow cost?	Around one working day per week, no reliable overview
Decision maker	Who signs?	Head of technical division, above €50,000 also management
People involved	Who can block?	IT security, works council
Picture of success	How is success measured?	Audit without follow-up requirements, coordination effort halved
Open question	What do we not know yet?	Existing contract with the current vendor, term unclear

Stakeholder view: the same solution needs a different justification for each role. The department asks about daily work, IT about operation and security, management about risk and numbers. Whoever tells everyone the same thing rarely convinces more than one person.

Conclusion

Selling products that need explaining is consulting with the goal of a deal. It demands understanding of the customer process, patience in discovery, clarity towards several decision makers, demos connected to daily work and a follow-up that does not depend on memory. Whoever builds that systematically does not sell louder but better, and wins customers who have understood what they are buying.

FIOXX takes on that work hands-on, individual phases or the whole cycle, and builds the system behind it in parallel. More under Sales & Revenue.