Why Do Organisations Buy?
It’s common practice for us in sales to sell the product or service. We walk in with the features, the integrations, the roadmap, and we pitch whoever agreed to take the meeting. We leave those meetings feeling great, only to realise months later that nothing has actually progressed. Reality is that we did nothing to move the needle. A buyer doesn’t sign the order because the product is good. They sign because handing over money and risk is cheaper than carrying the problem themselves. In this economic climate, no one spends for the sake of spending.
So when you strip any enterprise purchase back, you find three motivations under the surface. They’re in a constant game of cat and mouse: to save money, to make money, and to stay compliant. That’s it. Every business case, every signed contract, every budget that moves traces back to one of those three.
But it’s not the organisation that plays this game. It’s people, grouped into departments, each handed a piece of the puzzle. One team is tasked with integrating the two systems to bring processing times down by a day. Another owns the omnichannel experience that cross-sells the existing customer base. Another carries the data governance obligations in case of an audit. The risk doesn’t sit on the company. It sits in those lines.
So the work isn’t pitching harder. It’s finding those lines. Which processes carry the risk, and who owns them. That’s where Layer 1 starts.
Layer 1
Section titled “Layer 1”We’ll cover two tools to help you find where value sits in a business, and who owns it. The value chain shows you where in a business the work sits, and the APQC framework drops one level down to which process you’re actually touching.
Let’s start with the value chain.
Value Chain
Section titled “Value Chain”A value chain is the set of activities an organisation runs to serve its customers. It splits into two halves. Primary activities (work that directly delivers products and services) and support activities (functions that help deliver the primary work). Value is created across the chain end to end, with margin (profitability) being what’s left once you account for the cost of all those activities.
A value chain in sales is used to get a general understanding of an organisation and to build your hypothesis. Where is value created, where is it leaking and which part of the business is feeling this pain.
Let’s use an example: an operations field team running site and asset inspections on paper and spreadsheets.
Where does the value sit? The inspections are a primary activity - operations, the work of keeping assets running and signed off. But look at how it runs and it leans on the support row: the systems that hold the records, the technology the process depends on. Primary work, propped up by support.
Where do you think you can solve it? Your solution lands on that same operations work - that’s the value it creates. But it enters through support: it’s a system, so it comes in through the technology layer and the people who own it. You deliver in primary, but you get in through support.
Put the two together and the chain has told you something before you’ve spoken to anyone. The value is felt in operations. The fix runs through the technology underneath it. That’s your hypothesis.
The chain told you which part of the business. The APQC framework tells you exactly which process - and who’s standing on it.
APQC framework
Section titled “APQC framework”The value chain told you the area. APQC tells you the process.
APQC is a standard classification of business processes - effectively a map of every process an organisation runs, named and grouped. It exists so businesses can compare themselves to a common reference. Where the value chain is a broad read, APQC is the detail underneath it.
In sales, you don’t need the whole map. You need the one process your hypothesis pointed you at. In this case it’s under category 4.0, Manage Supply Chain for Physical Products.
Drill down and it gets specific. Inside 4.3, Produce, Assemble and Test, sits the maintenance work: 4.3.1.5 Plan for preventive maintenance, and 4.3.1.6 Request unplanned maintenance. That’s the process the field team runs on paper today - the checks that keep assets running, and the call-outs when something breaks.
Now it has a name and a number. Not “operations” in the abstract, but a specific, classified process you can point at.
And a named process has owners. An operations or maintenance lead who runs these inspections owns the problem and the outcome. IT owns the system it would run on - the data, the access, the integration. Two roles, two different stakes.