Why SaaS Implementations Often Underdeliver — And How Smaller Businesses Can Get Better Results

You rarely hear a leadership team say, "We introduced a new SaaS platform, everyone adopted it immediately, and it transformed the business exactly as planned."

More often, the story sounds like this:

"The system is live, but people are still using spreadsheets."

Or:

"We have more data than before, but we still do not trust the reports."

Or simply:

"We bought far more functionality than we use."

There is no reliable statistic proving that most SaaS implementations fail. The category is far too broad for a single number: introducing a basic expense-management application is not comparable to replacing a multinational company's CRM, ERP or customer-service infrastructure. And most of the evidence that exists comes from large enterprises — not from the smaller, owner-managed businesses this article is written for.

What the evidence does support is a more modest but still important conclusion: organisations of all sizes frequently struggle to realise the full value they expected from technology investments.

Research from PwC's 2026 Digital Trends in Operations Survey found that 89% of surveyed US operations and supply-chain leaders identified at least one reason why their technology investments had not fully delivered the expected results. Integration complexity, data problems and user-adoption challenges were among the most commonly reported barriers.[1] The survey covers large US enterprises with revenues above $100 million — a very different context from a 15-person professional services firm in Copenhagen or a 60-person manufacturer in Valencia. The specific barriers, however, map closely onto what smaller businesses encounter, even if the scale and remedies differ.

The starting point for smaller EU businesses is also worth understanding clearly. Eurostat's 2024 data shows that only 6% of EU SMEs had reached a very high level of digital intensity, with 40% recording low and 27% very low levels.[7] Among EU member states, Denmark and Finland lead — but even there, the majority of SMEs remain far from the frontier of digital capability. A joint 2025 report by Eurofound and Cedefop, the EU's vocational training agency, found that digital adoption in European SMEs is hindered primarily by limited resources and a lack of investment in building digital resilience — and that skills shortages remain a significant barrier to digital transformation across member states.[8] This is a meaningfully different starting point from the large enterprises that dominate most of the published research on SaaS implementation.

The picture is not entirely negative. KPMG's 2024 global technology research found that 72% of surveyed executives believed their digital-transformation decision-making usually generated business value, while 69% were broadly satisfied with the value produced by their technology investments.[2] Again, this sample skews toward larger, more resourced organisations. But it reinforces a point that is equally true for smaller businesses: the problem is rarely that SaaS technology does not work. It is that organisations often treat a software implementation as a product deployment when it is really a change to processes, responsibilities, information and behaviour.

For smaller businesses, that gap between installation and value tends to be sharper. There is less organisational slack to absorb a troubled implementation. There are fewer specialists to manage configuration, integration and data quality. And there is usually no dedicated project team — the people running the implementation are also running the business. Getting it right the first time matters more, not less.

This article explains why implementations underdeliver and how smaller organisations can improve their odds of obtaining lasting value from SaaS — without replicating the bureaucratic project frameworks designed for enterprises ten times their size.

1. The uncomfortable truth: software is often not the main problem

Sometimes the software really is at fault.

The vendor may have overstated its capabilities. A critical integration may be unreliable. The product may lack essential compliance, accessibility, security or reporting functions. Performance may be poor, or the platform may simply be unsuitable for the organisation's requirements.

But many disappointing implementations cannot be explained by product limitations alone.

The problem is often the environment surrounding the technology: unclear objectives, unresolved processes, weak ownership, unreliable data and insufficient attention to how people will actually use the system.

McKinsey describes digital transformation as the rewiring of an organisation to create value through the continuous deployment of technology at scale — a long-term change in how an organisation operates and improves, not a one-off installation project.[3]

Not every SaaS project is a digital transformation. A small business introducing an invoicing application does not need to pretend that it is reinventing the entire organisation. But the underlying principle still applies: the platform creates value only when it changes something meaningful about the way work is performed. Installing software and changing behaviour are two different things. The first can happen in an afternoon. The second takes sustained attention.

Typical signs that the organisational side has been neglected include:

• Employees maintaining parallel spreadsheets
• Managers requesting reports outside the new platform
• Users entering information only because it is mandatory
• Teams disagreeing about which figures are correct
• Extensive functionality remaining unused
• Nobody being accountable for benefits after launch

In a smaller business, these signs often appear faster and are harder to ignore. There is no IT department to absorb the friction. The managing director can see directly that the new CRM is not being used. That visibility is actually an advantage — if acted on.

2. Why SaaS implementations underdeliver

Although implementations vary enormously, the same patterns appear repeatedly across CRM, HR, finance, customer service and other business systems. In smaller organisations, they tend to emerge more quickly and with less room to recover.

2.1 The project begins with a product rather than a problem

A common starting point is a declaration such as:

"We need a new CRM."

Or: "We should move HR to the cloud."

Or, increasingly: "We need to introduce AI."

These statements identify a category of technology. They do not define a business problem.

Without a precise problem definition, almost every subsequent decision becomes subjective. Stakeholders request features because they appear useful. Vendors demonstrate their most impressive capabilities. The implementation accumulates fields, workflows, dashboards and automations without a clear connection to measurable outcomes.

In a smaller business, this is especially dangerous because there is usually no formal procurement process to slow things down. A founder sees a product demonstration, is impressed, signs up within a week and starts configuring it before anyone has asked what problem it is supposed to solve.

This pattern is well-documented in SMB-specific research. The OECD's D4SME survey of SMEs across seven countries found that among businesses that had not yet digitalised, 43% said they did not know where to start, and 40% said they did not know enough about digital tools to proceed.[9] The barrier, in other words, is often not cost or resistance — it is the absence of a clear problem definition and a structured way to evaluate options. Jumping to a product before defining the problem simply moves that gap further downstream, where it is more expensive to correct.

A more useful starting point would be:

"We are losing qualified sales opportunities because follow-up is inconsistent, customer information is fragmented and we have no reliable view of the pipeline. Over the next 12 months, we want to reduce lead leakage, improve forecast accuracy and increase revenue per salesperson."

The difference is substantial. The second statement makes it possible to evaluate whether a CRM is actually suitable and whether the eventual implementation produces value.

Before looking at products, the organisation should be able to answer four basic questions:

• What is not working today?
• What is the operational or financial consequence?
• What should be measurably better after implementation?
• Why is technology necessary to achieve that improvement?

If those questions cannot be answered clearly, the organisation is not yet ready to select a platform.

2.2 The software is evaluated through generic demonstrations

Most software demonstrations look excellent. They are designed to.

The data is clean, the scenarios are predictable and every process follows the intended path. The salesperson knows exactly where to click and avoids the parts of the product that are awkward, incomplete or irrelevant.

Real organisations are less orderly.

They have duplicate records, incomplete information, historical exceptions and processes that have evolved informally over many years. A business that has been operating for a decade on spreadsheets and email has embedded considerable complexity into those tools — complexity that does not disappear when a new platform is introduced.

A platform can satisfy an extensive requirements checklist and still fit the real organisation poorly. That poor fit often becomes visible only after launch: employees enter the same information in several systems, important exceptions require manual workarounds, or managers export data to spreadsheets before they can use it.

The solution is not necessarily to customise the software until it reproduces every existing habit. Some existing processes should be simplified or abandoned — and the new platform is often the opportunity to do that.

The objective is to identify the trade-offs before the contract is signed.

Instead of accepting a generic product demonstration, select a small number of critical user journeys and ask vendors to demonstrate them directly. In a smaller business, three well-chosen scenarios are usually sufficient. They might include:

• Converting an incoming enquiry into a qualified sales opportunity
• Handling a customer who operates through several entities or locations
• Processing a contract amendment or cancellation
• Onboarding a new employee and setting up their access

These scenarios reveal far more about operational fit than a list of several hundred features. Pay particular attention to the commercially important exceptions, not only the standard path. A platform that handles 90% of cases smoothly but fails on the 10% generating most of the revenue or risk may be the wrong choice.

2.3 Change management is reduced to a training session

In many implementations, the technical project receives months of attention while the people affected by it receive an email and a webinar shortly before launch.

The assumption is that once users understand which buttons to press, adoption will follow.

But knowing how to use a platform is not the same as having a reason to use it.

Employees may avoid a system because it creates duplicate work, conflicts with established routines or requires them to enter information that produces no visible benefit. In a smaller organisation, they may also simply ask themselves: "Does the owner actually use this? Do I think it will still be here in six months?"

Those are not unreasonable questions. Smaller businesses have shorter institutional memories and higher abandonment rates for technology that does not quickly prove its value. If the managing director continues running the sales review from a spreadsheet, the message to the team is clear, regardless of what the implementation announcement said.

Research from Prosci, a change management research and training organisation, consistently finds a strong association between the quality of change management and whether projects meet their objectives — with projects rated as having excellent change management far more likely to succeed than those rated as poor.[4] It is worth treating this finding carefully: Prosci has a commercial interest in demonstrating the value of change management, and its data is self-reported by participants who have already invested in the methodology. Projects with excellent change management also tend to have better leadership, clearer objectives and more resources — factors that are difficult to separate from the change management effect itself.

The OECD's 2025 D4SME survey of over 1,000 SMEs across ten countries adds a useful counterpoint: cultural resistance ranked near the bottom of reported barriers, with only 7% of respondents citing management resistance and 6% citing employee resistance as significant obstacles.[9] This suggests that the problem in most smaller businesses is not that people refuse to change — it is that they are not given a clear enough reason to, or enough support to do so. The practical implication is the same: people are more likely to adopt a new process when they understand it, see its relevance and observe their managers using it consistently. But the framing matters. Training to overcome resistance is a different intervention from training to build competence and confidence, and smaller businesses generally need the latter.

Eurostat's data reinforces why this matters disproportionately for smaller organisations: in 2024, 73% of large EU businesses provided ICT training to staff, compared to just 21% of SMEs.[7] The training gap is not simply a reflection of fewer resources — it compounds every other implementation challenge, because employees who have not been properly equipped are far less likely to adopt new tools effectively regardless of how well those tools are configured.

For a smaller business, this need not mean a formal change programme. It does mean:

• A credible senior figure who explains — in plain terms — why the change matters and what will be different
• An owner accountable for adoption, not only technical delivery
• At least one or two representative users involved before the design is finalised
• Role-specific training using familiar data and realistic scenarios
• Practical support immediately after launch, not a helpdesk ticket queue
• Managers using the platform in their own meetings and decisions from day one

This can be achieved informally in a small team. What it cannot be is an afterthought.

2.4 Integration and data are treated as technical details

A system can be configured well and still disappoint users because the information inside it is incomplete, duplicated, outdated or inconsistent with other applications.

Once people stop trusting the data, the value of the platform declines rapidly. Managers request manual reconciliations. Employees maintain private records. Teams debate which report is correct.

PwC's 2026 survey found that 87% of respondents said poor data quality had affected their organisation's ability to obtain value from digital initiatives, and identified integration complexity as among the most commonly reported barriers to realising expected results.[1] These findings come from larger enterprises, but the underlying dynamic is if anything more acute for smaller organisations, which typically have less structured data to begin with — customer records spread across email threads, contracts stored in personal folders, financial data split between an accountant's system and an internal spreadsheet.

Integration is not simply a matter of connecting one API to another. The organisation must decide:

• Which system owns customer, employee, product and financial data
• What happens when two systems contain conflicting information
• Which events must move between applications, and how quickly
• How errors will be detected and corrected
• Who is accountable for data quality on an ongoing basis

Without those decisions, integrations may function technically while the information remains operationally unreliable.

For European SMBs, there is an additional layer of complexity here that sits at the intersection of data architecture and legal obligation. See section 2.5 below.

2.5 EU and GDPR considerations for smaller businesses

This section addresses something most generic SaaS implementation guides omit entirely: for businesses operating in the European Union, the data decisions made during a SaaS implementation are not only operational — they carry legal weight under the General Data Protection Regulation.

This is not a reason to avoid SaaS. It is a reason to make better decisions about which platforms to use, how to configure them, and what data you put into them.

Understand where your data goes. Many SaaS vendors — particularly those headquartered in the United States — process and store customer data outside the European Economic Area. Before signing a contract, confirm whether the vendor offers EU-based data residency and whether any data transfers to third countries rely on Standard Contractual Clauses or another valid legal mechanism under Article 46 GDPR. This is especially important if you are processing personal data about EU residents, which for most B2B and B2C businesses means essentially all customer and employee data.

Get your processor agreements in place. Under GDPR Article 28, any vendor processing personal data on your behalf must do so under a written Data Processing Agreement. Most established SaaS vendors offer these as standard — but smaller businesses often sign up without requesting or reviewing them. Before go-live, confirm that a compliant DPA is in place for every SaaS platform that handles personal data.

Think carefully about what you migrate. Data migration is an opportunity to clean and reduce personal data, not just move it. Under the principle of data minimisation (Article 5(1)(c) GDPR), you should not carry over personal data you no longer have a legal basis to hold. Before migrating historical records, ask whether you actually need them and whether you have a valid basis to retain them in the new system.

Maintain a record of processing. If your organisation has more than 250 employees, maintaining a Record of Processing Activities (Article 30 GDPR) is mandatory. For smaller organisations it is still strongly recommended — and a SaaS implementation is a natural moment to document which platforms process what categories of data, on what legal basis, and with what retention period.

Check the AI features. Many SaaS platforms now include AI-powered features — content generation, predictive analytics, automated decision-making — often enabled by default. Some of these features involve sending data to third-party AI providers. Before enabling them, understand what data is being processed, whether it leaves the EU, and whether any automated decision-making triggers the obligations under GDPR Article 22. In most cases there are straightforward answers, but they need to be asked.

These are not bureaucratic extras. For a smaller business, a GDPR incident — a data breach, a regulator inquiry, or a complaint from a customer — can be disproportionately damaging. Building compliance into the implementation from the start is far less costly than retrofitting it later.

2.6 The implementation is starved of the right people

Because SaaS is marketed as faster and lighter than traditional software, smaller organisations sometimes assume the vendor will handle most of the implementation. The project is then assigned as a side responsibility to whoever has the most capacity that week.

The vendor may know how to configure the platform, but it cannot independently determine:

• What constitutes a qualified sales lead for your specific business
• Which customer data is genuinely necessary
• When an approval should be required
• Which reports management should actually use
• Which legacy workflows can safely be retired

These are business decisions, and they require people who understand the business.

An effective smaller-business implementation normally needs three perspectives, which may be covered by two or even one person in a very small team:

1. Business ownership: someone who understands the objectives, economics and priorities and has authority to make decisions
2. Process and adoption: someone who understands how work is actually performed and how behaviour must change
3. Technical awareness: enough understanding of configuration, data and integration to ask the right questions of the vendor

The important point is that none of these perspectives should be entirely absent. If the vendor is making business decisions by default — because no one internally has the time or authority to make them — the organisation will end up with a technically valid system that does not reflect its actual priorities.

2.7 Legacy complexity is carried into the new platform

A new system is often expected to solve problems created by the old one. But if the organisation simply migrates every field, workflow and exception, it may reproduce the same complexity in a newer interface.

In a smaller business, this often means importing years of informal workarounds — fields that exist because of one difficult client three years ago, approval steps that nobody remembers creating, reports that nobody reads but nobody has deleted. These accumulate silently and make the new platform feel as unwieldy as the old one from the first week.

KPMG's 2024 research found that organisations achieving stronger technology results were more likely to evaluate investment decisions continuously, use evidence rather than follow competitors and address technical debt rather than focusing only on new initiatives.[2]

A sensible implementation distinguishes between:

• Processes that are still necessary
• Processes that should be simplified
• Legal or commercial requirements that cannot change
• Historical habits that no longer create value

This does not require redesigning the entire business before launch. It requires enough honest challenge to prevent old complexity from being transferred automatically.

2.8 Going live is mistaken for success

Implementation teams naturally focus on launch. It is a visible deadline, and many workstreams converge around it.

But go-live is an event, not a business outcome.

A CRM can launch successfully without improving sales conversion. An HR platform can be available to every employee without reducing administrative work. A customer-service application can process tickets without improving response time or customer satisfaction.

For a smaller business, the consequences of this confusion are direct. The licence fee continues. The time invested in the implementation cannot be recovered. And if nobody is tracking whether the promised improvements have materialised, they probably have not.

Useful value measures might include:

• Lead-conversion rates
• Sales-cycle duration
• Forecast accuracy
• Customer-response times
• Processing costs
• Error rates
• Manual hours eliminated
• Percentage of key workflows completed inside the platform
• Active use by the intended roles

These measures should be linked to the original business problem. A baseline is essential. If the organisation does not know how long a process takes before implementation, or how frequently errors occur, it will struggle to demonstrate that the new system improved anything.

3. A more reliable way to implement SaaS in a smaller business

There is no method that guarantees success. But many avoidable problems can be reduced by applying a disciplined and proportionate process — one designed for organisations where nobody has the luxury of treating this as their only job.

3.1 Begin with a short implementation brief

Before contacting vendors, write a concise document describing the reason for the project.

It should cover:

• The business problem
• Its operational or financial consequences
• Three to five measurable outcomes
• The teams and processes included
• Important constraints (including any data residency or compliance requirements)
• The criteria that will determine the final decision

This does not need to be a polished 40-page business case. A clear one-page brief is more useful because people will actually read it. For example:

"Our current process requires the sales manager to spend two days each month reconciling forecasts from multiple spreadsheets. Within twelve months, we want to reduce this to four hours, establish one reliable pipeline view and ensure that at least 95% of active opportunities contain a documented next action."

That statement guides product selection, configuration and measurement after launch — and it is achievable in a single afternoon's work.

3.2 Evaluate real workflows rather than abstract functionality

Select the three to five journeys that matter most and document them at a practical level. For each journey, identify:

• What triggers the process
• Which roles are involved
• What information they need
• The important decisions and approvals
• Common exceptions
• The desired outcome
• The other systems involved

Use these journeys during vendor demonstrations and later during testing. A vendor who cannot demonstrate your actual scenarios — or who responds to them with lengthy caveats — is telling you something important.

3.3 Evaluate the complete operating environment

Feature comparisons are necessary but not sufficient. The evaluation should also examine:

• Data migration and quality
• API and integration limitations
• Identity and access management
• Audit logging
• Security and regulatory requirements
• Data location and international transfers (critical for EU businesses)
• Availability of a Data Processing Agreement
• Backup and recovery
• Reporting and export capabilities
• Administrative effort required on an ongoing basis
• Support arrangements
• Renewal and price-increase provisions
• Exit and data-retrieval terms

A platform that appears inexpensive may become costly once implementation, integration, administration and premium support are included. Even a small business benefits from a basic SaaS register showing which applications are used, who owns each one, what they cost, what data they hold, who has access, when the contract renews, and how data can be exported or deleted.

3.4 Treat adoption as an implementation workstream

Adoption should be designed alongside configuration, not added near the end.

The project team should identify which roles will change, who may experience additional work and which old routines must disappear. Training should be specific to the employee's role and should use recognisable data and scenarios. A salesperson needs to understand how the new platform affects opportunity management, not every feature in the administration console.

Good adoption planning answers four questions for each affected group:

• What is changing?
• Why is it changing?
• What must I do differently?
• What support will be available?

In a small team, this can be a 30-minute conversation rather than a formal programme — provided it happens before go-live, and provided managers reinforce the new process through their own behaviour from day one.

3.5 Design data and integrations early

Before migration begins, define the authoritative source for each important type of information.

For customers, products, employees, contracts and invoices, determine which system owns the record, who may create or change it, where the information must be sent and how errors will be handled.

Do not migrate every historical field merely because it exists. Migration is an opportunity to decide what must be retained, what should be cleaned, what can be archived and what no longer serves a purpose — including, for EU businesses, personal data that you no longer have a legal basis to hold.

3.6 Implement in manageable stages where possible

A large simultaneous launch may sometimes be unavoidable. But where the process allows it, a staged implementation reduces the consequences of mistaken assumptions and keeps the project manageable alongside normal business operations.

A CRM rollout for a smaller business might proceed through:

1. Core customer and contact data
2. Opportunity and pipeline management
3. Forecasting and management reporting
4. Any integration with marketing or service tools
5. Automation and additional users or locations

Each stage should deliver a usable improvement. It should not simply complete a technical component that produces no value until everything else is finished.

3.7 Measure value after launch

The organisation should establish a review cycle before the system goes live. For a smaller business, a practical cadence might be:

• Weekly check-ins during the first month
• A focused adoption review after 30 days
• A value review after 90 days
• Quarterly optimisation reviews thereafter

These reviews should combine system usage data with direct user feedback. Low usage does not automatically mean that employees are resistant — it may indicate unnecessary fields, a missing integration or a workflow that does not match reality. High login numbers do not prove that the platform is producing value; users may log in only to complete mandatory administration.

The review should examine three dimensions:

• Usage: Are the intended people using the system?
• Process: Are important workflows being completed correctly?
• Value: Are the relevant business outcomes improving?

4. How to recover an underperforming SaaS platform

An underwhelming implementation does not always need to be replaced. Many systems can be improved by revisiting the decisions that were overlooked during the original project.

Re-establish the purpose. Bring the relevant people together and define what the platform should achieve over the next 6 to 18 months — starting with business outcomes, not feature requests. The original rationale may no longer be valid, or the vendor may have developed capabilities that were not available at the time.

Investigate how work actually happens. Use application analytics, brief interviews and direct observation to understand who is using the platform, which functions they use, where work leaves the system, which steps users avoid and which reports managers actually trust. A workaround is usually a rational response to an impractical process, not evidence of obstruction.

Separate the causes. Classify problems before proposing solutions. They may arise from genuine product limitations, poor configuration, weak data quality, integration failures, unclear processes, insufficient knowledge, lack of ownership or contradictory management behaviour. Replacing the platform will not solve problems caused by weak governance or a lack of agreement about how the business should operate.

Fix the highest-value problems first. Correcting a single source-of-truth issue may create more value than implementing twenty minor feature requests. Simplifying one heavily used workflow may improve adoption more than another round of general training.

Relaunch the improved process. Material corrections should be treated as a focused relaunch. Explain what has changed, why it changed and what is expected. Ensure managers use the revised process consistently. Retire parallel spreadsheets and legacy tools only after the replacement has proved dependable.

Some platforms genuinely should be replaced — where essential requirements cannot be met, compliance risks are unacceptable, or correction would cost more than a controlled replacement. That decision should be evidence-based. Otherwise, the organisation risks repeating the same implementation mistakes with a different vendor.

5. A practical checklist for smaller businesses

A checklist cannot replace analysis, but it can prevent basic questions from being forgotten.

Before selection

• Have we defined the business problem in operational terms?
• Have we selected three to five measurable outcomes?
• Do we understand the critical user journeys?
• Have representative users contributed?
• Have we identified legal, security, data and integration constraints?
• For EU businesses: have we confirmed where data will be stored and whether a DPA is available?
• Do we have enough internal capacity to participate properly?

During evaluation

• Are vendors demonstrating our real scenarios?
• Have we tested important exceptions?
• Do we understand integration and data-export limitations?
• Have we evaluated security, access and audit controls?
• Do we understand the full cost of ownership?
• Have we reviewed renewal, pricing and exit provisions?
• Are we clear about where our process should adapt to the platform?

During implementation

• Is someone accountable for the business outcome?
• Have we defined authoritative sources for important data?
• Have integrations been tested under realistic conditions?
• Have representative users tested end-to-end workflows?
• Is training role-specific?
• Are managers ready to reinforce the new process?
• Have we recorded baseline performance measures?
• For EU businesses: is a signed DPA in place for every platform handling personal data?

After launch

• Are the intended workflows taking place inside the system?
• Are managers using its reports in routine decisions?
• Do users trust the data?
• Are integration failures monitored?
• Are the expected business outcomes improving?
• Are unused fields, reports or licences being removed?
• Is there a regular optimisation and governance review?

Conclusion

SaaS platforms do not automatically transform organisations — and the gap between what was promised and what was delivered is often widest in smaller businesses, where there is less capacity to absorb a troubled implementation and recover gracefully.

The evidence from large enterprises points to consistent patterns: integration complexity, data quality and adoption are the most commonly reported barriers to realising value. EU-specific research confirms that these same barriers operate at smaller scale too, compounded by limited resources, skills shortages and — critically — a tendency to adopt technology without a clear problem definition or a structured approach to change.[7][8][9] The OECD's finding that fewer than one in four SMEs is even aware of available support programmes for digitalisation suggests that the information gap is as significant as the resource gap.[9]

The best implementations — at any size — do not begin with a product demonstration. They begin with a clearly defined problem and a measurable outcome. They do not treat launch as success. They examine whether operational and commercial performance has actually improved. They do not assume that employees will change simply because licences have been purchased. And they do not leave data, integration and compliance decisions until the end.

For businesses operating in the EU, there is one additional discipline that belongs on this list: understanding where your data goes, who processes it and on what legal basis — before you sign the contract, not after.

The next time someone says, "We should implement this tool," the most useful first response may be:

"What will become measurably better — and what will we need to change, and agree to, to make that happen?"

That question does not guarantee a successful implementation. But it moves the conversation away from buying software and towards creating value.

Sources

[1] PwC, 2026 Digital Trends in Operations Survey: How AI Reinvents Enterprise Performance, April 2026. Survey of 767 US operations and supply-chain leaders at organisations with revenues of $100 million or more. Findings cited relate to the broader enterprise context; SMB dynamics may differ in scale but share common structural patterns.

[2] KPMG International, KPMG Global Tech Report 2024: Beyond the Hype — Balancing Speed, Security and Value, September 2024. Survey of 2,450 technology professionals across 26 countries and 8–9 industries, from organisations valued at $100 million or more.

[3] McKinsey & Company, What Is Digital Transformation?, first published June 2023, updated August 2024.

[4] Prosci, The Correlation Between Change Management and Project Success, June 2023; see also Prosci's Best Practices in Change Management, 12th Edition, 2023. Note: Prosci is a commercial change management training organisation; its research draws on self-reported benchmarking data from its client base and should be read as indicative rather than independently verified.

[5] Gartner, Gartner Predicts 75% of Enterprises Will Prioritize Backup of SaaS Applications as a Critical Requirement by 2028, August 2024. Prediction relates to large enterprises; smaller organisations should focus on understanding vendor data responsibility models and export rights rather than deploying dedicated backup infrastructure in the first instance.

[6] European Data Protection Board, Guidelines on Article 28 GDPR — Processor Agreements, and European Commission guidance on Standard Contractual Clauses for international data transfers, current versions. See also Article 5(1)(c), Article 22 and Article 30 GDPR for data minimisation, automated decision-making and record-keeping obligations respectively.

[7] Eurostat, Digitalisation in Europe — 2025 Edition, European Commission, 2025. Based on the EU survey on ICT usage and e-commerce in enterprises, covering businesses across all EU member states. Figures cited relate specifically to SME digital intensity and ICT training provision.

[8] Eurofound and Cedefop, SME Digitalisation in the EU: Trends, Policies and Impacts, Publications Office of the European Union, Luxembourg, 2025. Joint report drawing on Eurostat data, the 2024 European Working Conditions Survey and national policy review across EU member states.

[9] OECD, SME Digitalisation to Manage Shocks and Transitions: 2024 OECD D4SME Survey, OECD SME and Entrepreneurship Papers No. 62, OECD Publishing, Paris, 2024 (doi:10.1787/eb4ec9ac-en); and OECD, SME Digitalisation for Competitiveness: The 2025 OECD D4SME Survey, OECD SME and Entrepreneurship Papers No. 68, OECD Publishing, Paris, 2025 (doi:10.1787/197e3077-en). Both surveys cover SMEs across multiple OECD countries including several EU member states (France, Germany, Italy, Spain). Note: the 2025 survey was distributed through the platforms of commercial partners (Amazon, Intuit, Kakao, Rakuten, Sage); respondents are therefore more digitally engaged than the average SME population, which should be considered when interpreting findings about non-adoption barriers.