
Foundations
Assessing England's productivity software market by the job, not the category
Assess England's business productivity software market through buyer workflows, reliable demand evidence, delivery models and procurement checks.
Business productivity software is best understood as a set of tools that helps an organisation complete, coordinate or measure work. The label can cover task management, shared documents, customer records, workflow automation, scheduling, communications and reporting. It is not a single statistical market, and there is no dependable public figure for its value in England alone.
That uncertainty need not stop a useful market assessment. Start with a sharply defined workflow, identify the businesses that experience the problem, and collect evidence of their willingness and ability to change. This guide explains how to do that without turning broad business counts or technology surveys into a fictional sales forecast.
Research for this market guide closed on 5 September 2026. England figures are identified as such. UK-wide surveys are used only where their coverage and respondent base are relevant.
What to take away
- Define the job before the category, naming user, input, action and output.
- Business population counts are denominators, not counts of potential software buyers.
- Interest and adoption are separate from a purchase, so look for operational commitment.
- Company size is a useful filter but a poor persona for predicting buying routes.
- Implementation, migration and data preparation belong inside the product proposition.
Define the job before defining the category
The Department for Business and Trade's SME Digital Adoption Taskforce report discusses basic productivity-enhancing technologies including cloud, customer relationship management and enterprise resource planning software. That is a useful policy grouping, but it does not tell a supplier which job a customer wants done.
Define the product boundary
- Name the user
- Name the input
- Name the action
- Name the output
- State what it replaces
- Name the source of record
- Name who approves changes
A stronger definition names the user, input, action and output. For example, a five-person field service firm may need to turn emailed requests into scheduled visits and invoices. A regional training provider may need to control course records, tutor availability and attendance evidence. Those are different operating problems even if both products are sold under a productivity label.
Write the proposed boundary in one sentence. State what the product will replace, which system remains the source of record, who approves changes and what a successful handover looks like. This protects the research from category drift. It also makes interviews more revealing because prospective buyers can react to a concrete process rather than an abstract promise to save time.
What the available business counts can show
The Department for Business and Trade estimated 5.0 million private-sector businesses in England at the start of 2025. The same release says its regional allocation is based on the location of the head office. A company headquartered in London but operating elsewhere is therefore assigned to London for that table.
Two business counts, two universes
- 5.0 millionPrivate-sector businesses in England, start of 2025
- 2.73 millionUK VAT or PAYE registered businesses, March 2025
This is a population estimate, not the number of potential software buyers. It includes businesses without employees, companies with established systems and firms whose processes are not suited to the proposed tool. It should be used as a denominator from which an addressable segment is progressively narrowed.
The Office for National Statistics counted 2.73 million VAT or PAYE registered businesses in the UK in March 2025. Its population differs from the broader business population estimate because it draws on the Inter-Departmental Business Register. The two totals must not be mixed as though they measure the same universe.
For a market worksheet, choose the source that matches the customer definition. An employee scheduling product may start with registered employers in selected industries. A simple record-keeping tool for sole traders needs a source that includes unregistered businesses. Record the source date and unit beside every count, then apply only filters that can be defended.
Find demand in observable behaviour
Interest, adoption and a purchase are separate events. Search volume or survey awareness can help form a question, but neither establishes a budget. Stronger signals sit closer to an operational commitment: staff are rebuilding the same spreadsheet each week, a customer must meet a reporting duty, an existing contract is approaching renewal, or managers are paying for manual reconciliation.
AI use versus AI plans
- 16%Using at least one AI technology
- 5%Planning to use AI
The UK Business Data Survey 2026 reports technology use among businesses that handle digitised data. It describes differences by business size and by the sophistication of data practices.
The survey is not a census of all English firms. It does support one practical question: does the target customer already keep the data and management routines your proposed workflow needs?
A Department for Science, Innovation and Technology study, AI Adoption Research, estimated that 16 per cent of UK businesses were using at least one AI technology. Five per cent planned to do so at the time of its fieldwork.
Those figures belong to that study's definitions and sample. They do not measure the wider productivity software category, and should not be combined with percentages from surveys asking different questions.
Regulatory change can create a more specific signal. HMRC says eligible sole traders and landlords with qualifying income above £50,000 entered Making Tax Digital for Income Tax from 6 April 2026 and must use compatible software for digital records and submissions. That is relevant to products serving those workflows, not proof of demand for every accounting or collaboration application.
Segment buyers by operational setting
Company size is a useful filter but a poor persona on its own. Two ten-person businesses can have entirely different buying routes. One owner may select and configure a tool in an afternoon. Another organisation may require approval from finance, an external IT provider and a client that controls security requirements.
Four questions expose the buying setting quickly:
- Who feels the operational cost and who controls the budget?
- Which records contain personal, financial or commercially sensitive information?
- What must connect to the new system before it becomes useful?
- Can the customer change its process, or must the product fit an existing contract or rule?
The ONS registered-business release also reports local units as well as enterprises. That distinction matters for multi-site operations. A head-office buyer may want common reporting while branches need local permissions, resilient mobile access and a credible offboarding process. The resulting proposition is not merely more seats. It is a different implementation and governance problem.
Geography matters when support, training or on-site work is part of the offer. England-wide software can be delivered remotely, yet the cost of acquiring and onboarding buyers may vary by sector clusters, travel time and local partner coverage. Test one realistic route to market before presenting England as a homogeneous territory.
Choose a delivery and revenue model deliberately
A subscription can align recurring service with recurring payment, but it also creates continuing duties around availability, updates, support and secure account administration. A fixed implementation fee can fund migration and training, although the scope must distinguish routine setup from bespoke integration. Usage-based charging may fit variable workloads while making budgets harder for customers to predict.
The commercial model should follow the work. Map the cost of onboarding, support contacts, infrastructure, third-party services, renewal and customer departure. Then state what the buyer receives in the same unit used for charging. Avoid a headline comparison between monthly and annual prices if one package includes implementation and another does not.
The government's Software Security Code of Practice sets out 14 voluntary principles for organisations developing or selling business software.
It covers software services and distinguishes developers, distributors, resellers and in-house teams. It is not a certification scheme.
For a founder, it is a useful prompt to assign responsibility for secure design, build controls, maintenance and customer communication before choosing a route to market.
Treat implementation as part of the product
Product demonstrations normally show a clean account. A live customer brings duplicate records, inconsistent naming, former staff accounts, undocumented spreadsheets and exceptions that no one remembers approving. The market proposition therefore needs an answer for discovery, data preparation, configuration, training, acceptance and reversal.
The National Cyber Security Centre's guidance on using SaaS securely separates provider responsibilities from settings controlled by the customer. It covers identity, permissions, data, monitoring, incidents and leaving the service. A seller should turn those topics into an implementation responsibility matrix rather than implying that cloud delivery transfers every risk to the provider.
Plan an exit while planning the first import. Specify export formats, retention, account closure, restoration limits and the treatment of copies held by subprocessors. These details affect both procurement and engineering. They also reveal whether a low-friction trial can genuinely be reversed.
Build privacy and assurance into early decisions
Productivity tools frequently process staff, customer or supplier information. The Information Commissioner's Office says data protection by design and by default requires organisations to consider privacy from the design stage and throughout the lifecycle. Its guidance was updated in February 2026 to reflect the Data (Use and Access) Act 2025.
Before a pilot, list the personal information involved, its purpose, access roles and retention period. List exports and deletion route, then decide whether supplier and customer are controller or processor for each activity and obtain qualified advice where allocation is uncertain.
The ICO's controller and processor contract guidance describes mandatory terms for relevant written contracts and notes the guidance is under review. It is not a substitute for advice on a particular arrangement.
Buyers also need usable evidence. The NCSC's software customer assurance guidance suggests asking suppliers for claims about how their development practices meet relevant principles and requesting updates. A concise evidence pack can be more useful than unsupported statements that a service is secure.
A practical market test for England
Begin with one workflow and one reachable segment; recruit interviews from a stated frame, not merely friends or people answering a promotional post. Ask participants to demonstrate the current process where confidentiality permits.
Record how often the task occurs, who is involved, delay, rework and consequence of error. Do not ask whether they like an imagined product until the present behaviour is understood.
Next, test a small commitment. This might be permission to observe a second workflow, provide sample data, review a migration plan or agree a paid discovery scope. The form depends on the buying process. The aim is to distinguish polite interest from willingness to spend time, share risk or allocate money.
Keep an evidence ledger with five columns: claim, source, geography, observation date and limitation. Separate official statistics from interview notes and supplier assertions. Where the evidence does not support an England-wide conclusion, make a narrower statement about the tested sector, region or buyer type.
Finally, write a decision memo that can end in proceed, revise or stop. Include the workflow definition, eligible business population, observed demand, buying authority, implementation burden, security evidence, unit economics and unresolved legal questions. Do not convert a handful of favourable conversations into a market-share estimate.
What to verify before committing funds
Check whether the customer can extract usable data from its current tools, whether essential integrations have documented access and whether the proposed support model covers the hours when the workflow matters. Test accessibility with representative users. Price the work of onboarding and departure, not just hosting.
For an England launch, identify which claims rest on England evidence and which rely on UK findings. Set a review date for statistics, tax rules, security guidance and data-protection material. This draft remains on editorial hold and requires named editorial, fact-checking, data-protection, security and commercial review before publication.
Before you act
- Write the proposed product boundary in one sentence.
- Record the source date and unit beside every count.
- Choose a business count source that matches your customer definition.
- Test one realistic route to market before treating England as homogeneous.
- Map onboarding, support, renewal and departure costs before pricing.
- Assign responsibility for secure design and maintenance before choosing a route.
Common questions
Why is there no dependable public figure for England's productivity software market?
The article says business productivity software is not a single statistical market, and no dependable public figure exists for its value in England alone. Available sources cover different populations, such as the broader business population estimate and the VAT or PAYE registered business count, so they cannot be mixed.
How should a supplier use the 5.0 million private-sector businesses figure for England?
Treat it as a population estimate and a denominator, not the number of potential software buyers. It includes businesses without employees, firms with established systems and companies whose processes do not suit the proposed tool. Narrow it progressively to an addressable segment using filters you can defend.
What does the Software Security Code of Practice require of a software seller?
It sets out 14 voluntary principles for organisations developing or selling business software, covering software services and distinguishing developers, distributors, resellers and in-house teams. It is not a certification scheme. The article suggests using it to assign responsibility for secure design, build controls, maintenance and customer communication.
In this guide
- Turning a broad business count into an auditable productivity software market rangeEstimate England's addressable productivity software market without misusing broad business counts, mixed survey populations or unsupported revenue figures.
- Six signs of real demand for a productivity software idea, and how to read themUse six observable demand signals to test an England productivity software idea, while keeping UK surveys, regulation and customer behaviour in context.
- Subscription, managed or self-hosted productivity software over one worked yearCompare subscription, managed and self-hosted productivity software models on cost units, responsibility, implementation, security and exit terms.
- Entering the productivity software market in England, from trading entity to rehearsed departureUse this England market-entry checklist to test a software proposition, form the business, map data duties, prepare assurance and plan customer exit.
- Where the defensible productivity software opportunities are, from implementation to adoptionFind defensible productivity software opportunities in England through workflow depth, implementation support, assurance, integration and responsible adoption.



