The PPIT framework: the four factors that determine whether business automation succeeds or fails
You've invested in an automation project. The tool is selected, the implementation is done, the invoices are paid. But six months later, adoption is below 30 per cent. The system works technically, but almost nobody uses it. The investment has become a cost rather than an asset.
This isn't an exceptional scenario. It's a pattern we see time and again. And it almost never has anything to do with the tool.
In our blog Automating business processes: where do you start when you don't know where you stand?, we showed how to assess your organisation's automation maturity using five honest questions. The conclusion was clear: most organisations consistently overestimate where they stand. But knowing where you stand is only the first step. The question that follows is: how do you make sure an automation project actually delivers what you expect from it?
The answer isn't a better tool. It's the sequence in which you implement or expand business automation in your organisation. We'll show you how, using the PPIT framework: People, Process, Information, and Technology.
)
The PPIT framework: four factors, one sequence
In every automation project we guide, we work with the same four factors: People, Process, Information, Technology. Not because we love frameworks, but because these four elements ultimately determine whether a project succeeds or not.
The sequence is deliberate, technology comes last. Not because it doesn't matter, but because it only works when the other three are in place. Organisations that succeed tackle these factors in the right sequence. Organisations that get stuck start with technology and scramble to sort out the rest afterwards.
The PPIT framework isn't theory. It's the distillation of patterns we've seen across hundreds of projects.
)
)
People: who does what, and why would they?
The human factor is the most underestimated element in any automation project. Most automation problems aren't technical at their core. They're organisational: unclear responsibilities, teams working past each other, resistance to change that nobody voices out loud.
In many organisations, automation is something that gets done to teams rather than built with them. Here's how it typically goes: IT selects a tool, an external party configures it, training is delivered, and then people are expected to adapt their ways of working to the system. That doesn't work.
What we consistently see:
Marketing builds campaigns, but sales doesn't trust the leads, because nobody ever aligned on what a lead actually is.
Service speaks to customers every day and holds valuable insights, but those insights never reach sales or marketing.
IT builds integrations without context about the business problem, because nobody has mapped out which data needs to move between systems and why.
Everyone has an opinion about the tool, nobody has one about the process. Meetings about automation turn into discussions about features and dashboards, while the question "what are we actually trying to achieve?" rarely gets asked.
To get on top of these challenges, you need to be able to answer a few key questions: who owns the entire customer journey, not just one phase of it? Who decides which data goes into the system and which doesn't? And who is responsible for adoption once the implementation is "done"? RevOps is the answer to that question.
)
Case: change management as the deciding factor
At a B2B services company with 300 employees, we supported the implementation of HubSpot for sales, marketing, and service. On the technical side, things moved quickly. The real value came from the parallel change management approach: shared definitions, process design with end users, role-specific training, and weekly feedback loops after go-live. The result after one year: 94 per cent adoption, 40 per cent time savings on administrative tasks, and an internal user NPS of +45. Without those six months of change management? We'd now have a third tool that nobody uses.
)
Process: what are you actually automating?
Automate a bad process and you just get a bad process that runs faster. Yet the instinct in many organisations is to automate what exists, rather than first redesigning what should exist.
Processes are rarely built by design. They evolve organically and nobody can quite explain how they started. Ask how the lead process works and you'll get five different answers from five different people. A lead scoring model was built, but nobody remembers what assumptions it was based on. Those processes, with all their inefficiencies, workarounds, and exceptions, then get automated. That creates more problems than it solves.
The key principle: standardise before you automate. If the same process is being executed five different ways by five different people, don't automate five variants. Choose one way, clean it up, and then automate that one way.
)
Information: the promise versus the reality
This is where most business automation ambitions run aground. Organisations often claim they have plenty of data. But volume isn't the same as value. We hear it regularly: "We have a data warehouse, all the data is in there." Or: "We've implemented BigQuery, we can combine everything." Or: "We have 3 million contacts in our CRM, that's our biggest asset."
The reality we typically find: a data warehouse in a format that can't be activated directly. Definitions that differ by team. What is an "active customer"? Marketing, sales, and finance give three different answers. The connections between systems exist, but the match rate in reality often falls well short of expectations. And nobody dares clean up the data for fear of deleting something that might still be needed.
The core question for Information isn't how much data you have, it's whether that data is usable. Current, complete, consistent, and available for automation. Data quality isn't a one-off clean-up project. It's an ongoing responsibility that requires clear ownership.
In the blog 'Your CRM has 100,000 contacts. But how many are actually usable?' , we go deeper into how to make data quality measurable and how to set up governance.
)
Technology: the tool is the easy part
Technology is where organisations love to start, because it's tangible. You can get a demo. You can compare features. You can buy a licence and feel like you're making progress.
But technology is the outcome of good decisions in People, Process, and Information. Not the solution to problems in those areas. Selecting a tool before the other three factors are in place is putting the cart before the horse.
What we consistently see:
Tool selection based on features rather than fit with processes. The platform with the longest feature list wins the comparison, but half those features are never used.
Implementations that are technically "done" but don't connect to the way people actually work.
Integrations that move data around, but where nobody does anything with that data.
Enterprise licences with premium features chosen "for the future", while the basic functionality isn't even being used.
HubSpot, Salesforce, Microsoft Dynamics, Adobe Experience Cloud: they can all work. They can all fail, too. The tool is rarely the bottleneck. The right tool is the one that fits your People, Process, and Information, not the one with the best demo.
Questions worth asking before you commit to a tool: what problem does it solve, and have we defined that problem clearly? Do we have the capacity to adopt and maintain it after implementation? Does it match our current data maturity, or are we getting ahead of ourselves?
People, Process, Information, Technology: the four factors working together
The four factors don't exist in isolation. They're constantly influencing each other.
How the four factors influence each other:
People without Process leads to good intentions without structure. Everyone wants to collaborate, but nobody knows how.
Process without Information leads to beautiful flowcharts that don't hold up in the real world, because the data needed to make decisions simply isn't there.
Information without Technology leads to knowledge that can't be activated.
Technology without People, Process, and Information leads to expensive systems nobody uses, that don't fit the way people work, and that contain no usable data.
The real skill is in keeping all four factor moving forward together. Not as stages you tick off and move on from, but as dimensions you keep revisiting.
Automation isn't a project: it's a capability
The PPIT framework isn't a checklist you work through once. It's a way of thinking about automation that you apply continuously. The organisations that succeed ask the right questions in the right order. They start with the business problem, not the platform.
)
Case: personalisation at scale
An international organisation wanted to make their communications more relevant across countries, languages, brands, and product lines. The question wasn't: which tool can send out 1,600 variants? The real question was: how do we design a system where content, data, and intelligence work together?
The solution combined template-based content, clear governance, better customer profiles, and a personalisation engine that automatically assembles the right content blocks. The result: more relevant communication, less manual production work, and a foundation that remained scalable.
The lesson: personalisation isn't a campaign feature. It's a system choice.
Want to put the complete PPIT framework to work?
Download the whitepaper 'CTRL+SHIFT: The four factors that determine whether business automation succeeds or fails'. Including real-world examples and a readiness check to assess where your organisation stands.
)