Name the work before the software when choosing productivity tools and suppliers

Business productivity software tools and providers are easier to compare after the team has defined the work that must improve. Starting with a catalogue encourages feature collecting. Starting with a delayed approval, an unreliable handover or an invisible workload produces a testable buying question.

This guide is for an organisation operating in England. It covers selection, supplier checks and implementation, but does not recommend a product or decide whether a contract, privacy arrangement or security control is acceptable.

UK data-protection and cyber-security sources apply across the UK. Government technology and commercial frameworks are identified as public-sector material, not rules for every private company, and research was checked on 5 September 2026.

What to take away

Name the work before the software

Describe one troublesome workflow on a single page. Mark its trigger, participants, decisions, information, exceptions and finish point. Add the present evidence: elapsed time, returned work, missed deadlines, duplicate entry or avoidable support contacts. A statement such as improve collaboration is too vague to assess.

Interview people who do the work and those who receive its output, then ask where they wait, switch systems, create private spreadsheets or chase an answer. Include colleagues using assistive technology, working away from a desk or with limited connectivity.

Resulting needs should describe an outcome, not a desired feature. For example, a manager needs to see who owns the next decision without opening every project.

The government's Technology Code of Practice starts with user needs and also considers accessibility, open standards, security, privacy, integration, purchasing and sustainability. It is a cross-government standard, so a private business in England is not bound by its spend-control process. Its headings are nevertheless a useful challenge to a narrow feature list.

Decide whether the underlying problem deserves a new tool. A clearer rule, a removed approval or better use of software already licensed may be enough. A purchase that preserves a confused process can make the confusion faster and harder to leave.

Turn needs into an evidence pack

Split the requirement into four layers. First, write a small number of non-negotiable conditions. These might concern a necessary integration, an accessibility need, a contractual boundary or an export format. A candidate that misses a genuine gate should not recover by scoring highly on attractive extras.

Second, create scored outcomes. Give more weight to frequent, costly or risky work. Each score needs observable evidence: a configured demonstration using the buyer's scenario, a sample export opened independently, or a written response tied to the proposed service. A tick beside has reporting reveals little about whether the intended reader can answer the intended question.

Third, capture operating effort. Count administration, permission reviews, training, data preparation, support and reconciliation with another system. The cheapest subscription can still be the costliest option if every team maintains a workaround. Use one time unit and one planning period across candidates, and label all estimates.

Fourth, record uncertainty. Tell a published commitment from a sales answer, an observed trial result from a vendor claim, a current function from a roadmap item.

The National Cyber Security Centre tells buyers to decide the confidence they need in a cloud provider's security assertions. It says to check whether independent evidence covers the relevant service and configuration in its cloud-provider selection guidance.

Choose the right route to market

A direct software subscription is only one route. A buyer may deal with the software vendor, a reseller, a managed service provider or an implementation partner. One organisation may fill several roles. Map the contracting party, product owner, configuration team, support desk and sub-processors before comparing proposals.

Direct purchasing can shorten the buyer to product owner line, but does not guarantee local implementation help or negotiable terms. A reseller may combine licensing and support, while product defects remain another party's responsibility.

An implementation partner can handle design, migration and training, yet the customer may still hold the main software contract. Ask each party to state what it owns and where it hands an issue on.

Public bodies have additional routes and duties. The Government Commercial Agency describes G-Cloud 15 as a framework for public-sector purchases of cloud hosting, software and support. Its current page says availability is expected in the week beginning 7 September 2026, and G-Cloud 14 remains available until 28 October 2026.

A public buyer must check the live framework position and its procurement obligations. A private company should not treat framework presence as a universal quality mark.

Make demonstrations do real work

Send every shortlisted supplier the same compact scenario, sample data and questions. Ask the person who would actually configure the service to demonstrate the journey from entry to output. Include an exception, such as a returned approval or a leaver whose access must end. Record what happened and which settings were required.

A trial needs a written hypothesis. It might test whether five users can hand over a case without a separate status spreadsheet or whether an administrator can produce a usable export within an agreed time.

Define the starting condition, test participants, permitted data, observation method and stop rule. Do not load live personal or confidential information simply to make a trial realistic.

Keep vendor-led demonstrations separate from buyer-run observations. Suppliers know their own products and can explain intended operation, but a polished route may omit awkward exceptions. Equally, an inexperienced trial user may mistake poor configuration for a permanent product limit. Record both perspectives rather than forcing them into one score.

Examine fit beyond features

Integration claims need detail. Identify the direction of data movement, trigger, frequency, fields, permissions, failure alert, retry behaviour and owner. The government's open standards principles are written for government technology, but their attention to interoperability and avoiding supplier lock-in suggests useful questions for any buyer. Ask whether common file formats and documented interfaces will preserve a practical route out.

Accessibility belongs in the evidence plan, not in a late questionnaire. State the tasks and user needs that must be checked. Seek relevant product documentation, then let people who use the required access methods attempt representative work. A conformance statement is evidence to examine, not a substitute for testing the buyer's configured workflow.

Support also needs a scenario. Specify operating hours, contact routes, severity definitions, response targets and escalation ownership. If the sales conversation, implementation and help desk involve different organisations, follow one hypothetical incident across all three. The aim is to expose gaps before an outage does.

Scale due diligence to the consequence

The depth of review should follow the information, dependency and harm involved. A simple board for public event tasks does not demand the same assurance as software containing employee records or controlling a critical dispatch process. Write the risk statement first, then request evidence proportionate to it.

For a UK registered company, Companies House provides company details, officers, filing images, charges and insolvency information. Those records help confirm identity and status; they do not establish product quality, solvency, security or contractual performance. Resolve discrepancies with the supplier and, where exposure warrants it, obtain professional financial or legal checks.

Security review should cover the actual service boundary, including hosting dependencies. Ask about identity controls, administrator protection, logging, backups, recovery, vulnerability handling, incidents and customer configuration. The NCSC's guidance on using SaaS securely makes clear that customers retain responsibilities for matters such as onboarding, offboarding, authentication, data handling and monitoring.

If the service processes personal data for the customer, the controller cannot outsource accountability. The Information Commissioner's Office says a controller should use only processors providing sufficient guarantees, considering their expertise, resources and reliability, and monitor compliance over time in its processor due-diligence guidance.

The ICO page currently carries a review notice following recent legislation. A qualified practitioner must apply current law to the proposed arrangement.

Compare the whole commercial position

Put like-for-like assumptions beside each price. Record user count, plan, billing interval, tax treatment, implementation, storage, support, integrations, training and expected internal hours. Do not fill an unknown price with a convenient market average. Ask for a dated quote or leave the cell unresolved.

Review service description and legal terms together. Clarify renewal, price-change notice, service changes, suspension, support, data location, sub-processors, intellectual property, confidentiality, liability, termination and dispute route. The ICO lists minimum content for relevant controller-processor arrangements in its contract guidance. That checklist does not settle the wider commercial bargain.

Require legal, privacy, security and procurement specialists to review the documents appropriate to the risk. A sales summary is not the agreement. Nor does a certificate necessarily cover the service, territory and configuration being bought.

Negotiate the exit while there is competition

Test departure before signing. Ask for a representative export, its schema, attachment handling, audit history and administrator steps. Establish how long extraction remains available, what help costs, when access stops and how deletion is evidenced. Identify information held in integrations and local copies too.

Current government guidance on managing technical lock-in recommends open standards and formats for software services and examines migration, exit costs and skills dependence. It addresses government cloud use, but the commercial questions transfer: can the buyer retrieve usable records, rebuild necessary connections and continue essential work during a move?

A credible fallback may be deliberately modest. It can specify read-only access, a controlled spreadsheet, a queue freeze or a return to the previous tool for a limited period. Set the trigger and decision maker before launch.

Move from selection to controlled adoption

Name one accountable owner for the change and separate product administration from business-process ownership. Configure roles, retention, notifications and integrations in a non-production space where practical. Prepare support, training, migration reconciliation and a rollback decision before inviting a wider group.

Consult affected staff early when work practices or performance information may change. Acas explains that consultation involves talking and listening about organisational issues and changes, and distinguishes good-practice consultation from circumstances where law prescribes a process. Its remit is Great Britain. Employers should obtain employment-law advice if contracts, collective arrangements or monitoring are implicated.

Start with a bounded group and real tasks that do not expose uncontrolled information. Measure the previously defined outcome, record defects and watch the old workaround.

Government service guidance describes private beta as limited use that creates opportunities to learn and improve before wider release in its account of the beta phase. Private businesses need not copy public-service phases, but staged adoption is a sensible risk-control pattern.

At the decision point, choose explicitly among proceed, revise, pause and reject. Preserve the evidence and assumptions, not just the winning score. Schedule reviews for renewal, material feature change, supplier change, new data use and deterioration in service.

A practical next move

Select one workflow that currently causes measurable friction. Write its user need, one hard constraint, three weighted outcomes, one risk boundary and one exit test. That one-page buying brief is enough to begin a disciplined market scan.

It is also small enough for users, finance, security, privacy and commercial reviewers to challenge before a supplier conversation locks in the wrong answer.

Before you act

Common questions

Why is a vague goal such as improve collaboration a poor basis for buying software?

The article says such a statement is too vague to assess. A delayed approval, an unreliable handover or an invisible workload produces a testable buying question, and the resulting needs should describe an outcome rather than a desired feature.

What should a buyer record about integration before choosing a supplier?

Identify the direction of data movement, trigger, frequency, fields, permissions, failure alert, retry behaviour and owner. The article also suggests asking whether common file formats and documented interfaces will preserve a practical route out.

How should a buyer treat a supplier's security claims during due diligence?

Distinguish a published commitment from a sales answer and an observed trial result from a vendor claim. The NCSC advises deciding how much confidence you need in a cloud provider's assertions and examining whether independent evidence covers the relevant service and configuration.