Enterprise Selling Has a Complexity Problem

Why conventional selling can’t keep pace

Graham Roberts

July 20, 2026

Why this matters:

Enterprise technology is more capable, more connected and more strategically important than ever.

It’s also getting harder to sell.

Sales cycles drag on. Buying groups get bigger. Requirements shift. Forecast dates move. Strong solutions lose to delay, indecision or no decision at all.

These symptoms usually get treated as sales-execution problems.

Weak qualification. Poor discovery. Limited executive access. Bad opportunity management. Not enough urgency.

Any of those might be true.

But they don’t explain the bigger issue.

The defining condition of enterprise technology today is not AI.

It's complexity.

AI is speeding things up. But the impact of technology decisions now reaches wider and deeper into the enterprise than conventional buying processes and selling approaches were built to handle.

In this changed environment, the seller’s job isn’t only to explain the solution. It’s to help the customer see the bigger picture, align the people involved and make technology decisions with confidence.

That role has to evolve now. Sellers who remain focused on product, price and process risk being treated as transactional suppliers — increasingly filtered, compared and managed at arm’s length.

Complexity obscures the real issues

The difficulty exists on both sides of the deal. Sellers struggle to move opportunities forward. Customers struggle to understand, align around and act on decisions whose impact extends far beyond the technology itself.

It’s not that sellers have forgotten how to sell, or that customers have simply become more cautious, difficult or indecisive.

The environment has changed.

A significant technology decision now sits inside a dense system of business priorities, stakeholder interests, technical dependencies, risks and value assumptions. The more complex that system becomes, the harder it is to see what the real problem is, who owns it and what must change to solve it.

VUCA isn’t just a buzzword – it’s at the heart of the problem

Volatility
Conditions change while the decision is being made. Priorities, budgets, regulations, technologies and market assumptions may all move.

Uncertainty
The customer cannot reliably predict implementation difficulty, adoption, outcomes or the future value of the investment.

Complexity
Systems, stakeholders, initiatives and dependencies interact. Cause and effect becomes difficult to isolate.

Ambiguity
Different stakeholders interpret the same situation differently. The problem, the desired outcome and even the meaning of success may remain contested.

A solution can be technically sound, commercially credible and capable of producing real value, yet still be hard for the customer to understand, justify, approve and adopt.

Because customers don’t always start with a complete understanding of their own situation.

No single person necessarily sees the whole picture.

The customer may know that something has to change without having a shared view of:

what’s actually wrong;
why it’s happening;
which outcomes matter most;
what else has to change;
who owns the result;
how value will be realised.

This is one reason conventional sales discovery can fail even when it’s done competently.

Because it assumes the answers already exist somewhere inside the customer organisation, and the seller’s job is simply to uncover them.

In a complex environment, those answers may not exist yet — at least not in a complete or agreed form.

How did we get here?

This didn’t happen overnight.

Enterprise technology has moved through three broad eras. At each stage, the capability and potential value of technology increased.

era 1

1960s – 1980s

Automation

Early automation of visible, contained business systems.

Understanding of needs: Strong

Solution clarity: Clear

Perceived value: High

Complexity level: Low

era 2

1990s – 2000s

Integration

Client-server, ERP expansion, middleware

Understanding of needs: Clear

Solution clarity: Strong

Perceived value: High

Complexity level: Moderate

era 3

Today

Transformation

Cloud, AI/ML, microservices, platform economy

Understanding of needs: Fragmented

Solution clarity: Vague

Perceived value: Hard to define

Complexity level: High

Between Era 1 and Era 2, the question shifted from “Can this technology perform the task more efficiently?” to “Can this technology work across our existing systems and processes?”

But today, in Era 3, the question is: “Can we confidently make this change across the organisation, and will it produce the outcomes we need?”

As providers add value and sophistication to their solutions, they also make those solutions harder for customers to understand, evaluate, implement and use well.

Added value brings added complexity.

There’s a similar argument on the investment and benefits-realisation side. As technology moves from automation to business transformation, its strategic importance rises. But so does the level of organisational change, risk and uncertainty required to produce value.

The six sources of complexity

Complexity doesn’t come from one place.

It develops across the customer’s business, organisation, technology, stakeholder environment, value logic and external ecosystem.

And each source affects the others.

Business complexity

The investment affects more than one operational problem.

Enterprise technology can influence operating models, service delivery, customer experience, workforce effectiveness, cost structures, asset performance, resilience, compliance and strategic transformation.

The customer has to connect one investment to several business outcomes, often owned by different functions.

Organisational complexity

Different functions want different things.

Finance may want cost discipline.

Operations may want reliability.

IT may want architectural consistency.

Security may want lower exposure.

Users may want simplicity.

Executives may want growth, resilience or transformation.

All of those priorities are legitimate, but they’re not automatically aligned.

Technical complexity

The solution has to coexist with what’s already there.

The customer environment may include:

legacy systems;
cloud platforms;
integration layers;
enterprise data models;
cybersecurity controls;
identity systems;
technical debt;
shadow IT;
architectural standards.

A new solution has to fit into that environment before it can improve it.

Stakeholder and decision complexity

More people don’t automatically produce a better decision.

Buying groups expand because organisations are trying to reduce risk and improve decision quality.

But larger groups can also create:

fragmented ownership;
conflicting priorities;
inconsistent evaluation criteria;
unclear authority;
repeated reconsideration;
late stakeholder entry;
consensus failure;
decision avoidance.

The buying group is supposed to manage complexity, but it can become another source of it.

Value complexity

Cost and Value sometimes don't reside in the same place.

Customers may face:

costs in one function and benefits in another;
immediate investment and delayed returns;
measurable savings alongside strategic value;
avoided losses that are hard to prove;
outcomes that depend on adoption;
uncertain baselines;
overlapping transformation programmes;
value that can’t be attributed to one system alone.

This is why the business case can’t be treated as ROI arithmetic.

The business case is an alignment mechanism.

It should align the organisation around:

why the change matters;
what outcomes are expected;
how technology capability becomes business capability;
who owns the required changes;
how value will be measured;
what could prevent the outcome.

External and ecosystem complexity

The decision extends beyond the customer and the seller.

The outcome may be shaped by:

regulation;
market volatility;
competitive pressure;
vendor roadmaps;
implementation partners;
industry standards;
geopolitical risk;
supply-chain dependencies;
changing customer expectations;
rapid technological change.

The customer isn’t buying a product in isolation – it’s making a long-term choice inside an ecosystem.

Complexity doesn't simply increment - it compounds

These aren’t six separate problems – they’re an interconnected system.

More dependencies → More stakeholders → More interpretations → More disagreement → More perceived risk → Slower decisions → Stalled opportunities

But even that is too tidy, because complexity moves.

The business environment changes while the decision is being made. Technology changes. New stakeholders arrive. Existing ones leave. Agendas shift. Assumptions weaken. New dependencies appear. The path from investment to outcome may have to be reworked.

In The Information Paradox, John Thorp describes four dimensions through which this complexity expands:

Dimension	What changes in transformation-era decisions
Linkage	More actions, investments and outcomes have to connect for value to occur
Reach	The change extends across more functions, organisations and ecosystem participants
People	More people have to change what they understand, decide or do
Time	Benefits take longer to emerge and become harder to predict

In transformation programmes, those dimensions change over time too.

A one-off business case or a static discovery document can’t govern a decision whose conditions keep moving.

More capability doesn’t automatically create more value

Technology provides capability, but the organisation creates value by applying that capability through changes to:

business processes
operating practices
roles and responsibilities
skills and behaviours
incentives
management systems
governance
strategy

That’s why two customers can buy essentially the same technology, and get very different results if they’re not applying it through the same programme of business change.

One may align stakeholders early, redesign the right processes, assign ownership, manage adoption and measure outcomes.

The other may implement the software successfully but leave the surrounding operating model more or less untouched.

The result: the product can work in both organisations, but the realised value may be completely different.

In The Information Paradox, Thorp makes this distinction clearly: technology is an enabler, but the benefits depend on how the business applies it — including changes to work, processes, structure and management.

So the real enterprise decision isn’t simply:
Which technology should we buy?

It’s:

Which programme of business change are we prepared and able to execute?

And that exposes the central weakness in conventional enterprise selling:

Most methodologies are built to qualify and progress the technology opportunity.

They’re not built to help the customer understand the wider situation, align the people involved, or govern the change needed to realise value.

At this point, many sales leaders will be thinking:

But qualifying and progressing the deal is exactly what I care about.

Sure it is, but here’s the thing: it’s often that “other stuff” that decides whether the deal moves to a successful conclusion.

“Other stuff” builds confidence. It brings conflicting stakeholders into alignment. It strengthens the value case. And once the contract is signed, it shapes adoption, renewal, expansion and customer lifetime value.

So this work isn’t separate from winning the deal.

It’s often what wins the deal — and shapes the relationship that follows.

Why conventional selling hasn’t kept pace

Most established sales methods are still useful when they improve:

qualification;
stakeholder identification;
opportunity discipline;
forecast visibility;
competitive positioning;
management control.

Those things matter.

But they were built mainly to help the seller navigate and progress an opportunity and, through CRM and a common sales vocabulary, give sales leadership better visibility.

They assume that:

the customer’s problem can be uncovered through discovery
the buying process already exists and can be mapped
decision criteria can be identified
value can be demonstrated
the opportunity can then move through defined stages

In simpler environments, those assumptions may be good enough.

In complex enterprise decisions, they aren’t.

Question sets aren’t diagnosis

Conventional sales training usually gives sellers solution-specific question sets.

Those questions are designed to confirm whether the customer has problems the vendor’s solution was built to solve.

They may improve consistency across a sales team. They may help establish fit. They may produce enough information to qualify the opportunity or prepare a demonstration.

But they’re usually limited in depth and direction.

They ask:

Do you experience this problem?
How significant is it?
What’s the impact?
Who’s affected?
Would solving it matter?

They don’t necessarily uncover:

why the problem exists
how it connects to other business conditions
whether stakeholders define it in the same way
what assumptions are shaping the requirement
which changes outside the technology are needed
why previous attempts failed
what could prevent value from being realised

At scale, that creates a sales pipeline of qualified opportunities all built on poorly diagnosed customer situations.

Problem confirmation isn’t the same as situation diagnosis.

You must draw a distinction between the superficial questioning used to line up a known problem with a solution, and a more interactive process that expands the customer’s understanding of its own problem and alternatives.

Most enterprise sales organisations are equipped for the first.

Product expertise creates its own blind spot

Sales and technical teams live with the solution every day. They understand its architecture, capabilities, use cases and potential value — often better than any one person inside the customer organisation understands the whole customer situation.

That closeness createsThe Curse of Knowledge.

What seems obvious to the vendor may still be fragmented, contested or invisible inside the customer.

Conventional sales organisations often assume the customer already understands:

the complete problem
the implications of the solution
the value connection
the implementation requirements
the organisational changes required
the path from adoption to measurable outcome

Often, they don’t.

And because institutional knowledge is spread across the buying group, no single stakeholder may be able to close the gap alone.

So, confirming fit isn’t enough.

The vendor has to help the customer build a more complete understanding of its own situation. That’s a materially different capability from what most sales organisations are built and trained to deliver.

The consensus decision-making fallacy

In complex decisions, senior executives often push ownership into a broader group and call the result decision by consensus.

There’s a legitimate reason for that.

The people who have to implement the decision, and live with it, need to support it.

But consensus does something else too. It spreads the risk of being wrong.

A decision made collectively is less likely to leave one executive carrying the full consequences if the outcome disappoints. So the process becomes partly about building commitment and partly about distributing accountability.

That creates a paradox. Because the broader the group, the more likely it is to expose:

conflicting priorities;
different definitions of the problem;
competing success measures;
functional agendas;
uneven risk tolerance;
different views of value;
disagreement over who owns the outcome.

Consensus is meant to reduce decision risk.

But when those differences surface and no one helps resolve them, the process slows down, confidence drops and no decision starts to look like the safest option.

Consensus doesn’t remove complexity. It often reveals how much complexity was already there.

Consensus can’t be forced on those groups, just as “closing the deal” can’t be forced.

What the vendor can do is help by making those differences visible, building a shared understanding of the situation, and resolving enough of the conflict for them to make defensible choices.

Managing complexity demands more than sales training delivers today

Conventional enablement usually provides:

concepts;
messaging;
qualification frameworks;
question sets;
product knowledge;
objection responses;
stage criteria;
workshop practice.

Those things can improve knowledge and consistency across a sales organisation.

But the capability required to operate inside a complex enterprise decision is contextual and integrative. It can’t be delivered as knowledge transfer alone.

And all of that has to happen while the situation changes, stakeholders disagree and commercial pressure continues.

The gap isn’t simply what a sales organisation knows.

It’s whether that organisation can actually operate this way inside a live customer system.

Turning complexity into better decisions and selling success

Customers need more than product expertise and a well-managed sales process. They need help understanding the situation, aligning the people involved and building a decision that can withstand scrutiny.

That responsibility continues after the sale. If value depends on changes to process, behaviour, ownership and adoption, the provider has to preserve the logic between what was promised and what is delivered.

That means Marketing, Sales, Solution Engineering, Delivery and Customer Success working from the same customer value logic.

It also requires stronger capabilities: value engineering, consultant-grade diagnosis, and a deeper understanding of the systems, people and processes that shape the enterprise environment.

Together, these form the basis of a Customer Operating Model that aligns the provider, its ecosystem and the customer around the problem, the decision and the value to be realised.

That’s the current capability gap. Closing it isn’t about more training. It’s about better skills and a better operating model.

A better operating model only becomes real when applied on live opportunities with real stakeholders.

These capabilities can’t be embedded through a workshop alone. They have to be developed inside real accounts, over enough time to become repeatable.

ASAP was built to do exactly that.

About ASAP

ASAP (Avvate Strategy Acceleration Program) develops the capability to engage, shape and progress complex enterprise opportunities in the field.

It’s not another sales methodology. And it’s not a single training event.

Two capabilities are especially relevant to the complexity described in this article.

Enterprise Solution Consulting

Enterprise Solution Consulting moves the conversation from confirming solution fit to developing customer understanding.

Conventional discovery usually starts with the solution category and works backwards towards the customer’s problems.

Enterprise Solution Consulting starts with the customer situation.

It develops the capability to:

distinguish symptoms from underlying causes;
understand the wider business and systems context;
map stakeholder interests and dependencies;
identify conflicting interpretations of the problem;
help the customer build a shared view of the situation;
connect the proposed response to the wider transformation environment;
improve the quality of the customer’s decision process.

Applied Value Engineering

Applied Value Engineering turns value from a claim into shared, testable logic.

Applied Value Engineering develops the capability to build the value case through the engagement instead of attaching it near the end.

It connects:

Solution capability → Business capability → KPI → Functional objective → Strategic initiative → Financial driver → Enterprise value

That creates a defensible line of sight from technology investment to business impact.

It also makes the business case useful for more than approval.

It becomes shared decision logic that can stand up to scrutiny across Finance, Operations, IT, Risk and executive leadership.

ASAP develops these capabilities through live field application, structured tools, coaching, opportunity reviews and repeated use over time.

Rethinking the true role of Customer Success Management

Customer Success shouldn’t inherit promises. It should inherit the logic, ownership and evidence needed to turn those promises into results.

Its role isn’t just to track CSAT, NPS and renewal risk. It’s to drive benefits realisation, build customer advocacy and strengthen customer lifetime value.

That means carrying the original value logic beyond the sale:

the business problem;
the agreed outcomes;
the stakeholders and owners;
the assumptions behind the value case;
the changes required;
the measures of success.

A>COM (Avvate Customer Operating Model) connects Sales, Solution Engineering, Delivery and Customer Success around that shared logic, so it doesn’t fragment after contract signature.