Separate gates from scores when selecting productivity software

Business productivity software software selection goes wrong when a long feature grid hides the few conditions that matter. A defensible decision uses gates for genuine necessities, scored evidence for trade-offs and a separate record of uncertainty.

This method is designed for an organisation in England. It is not a verdict on any vendor, and it cannot approve security, privacy or contractual terms. The public-sector guidance below supplies useful questions, not mandatory rules for private firms.

What to take away

Write a testable brief

Choose a single workflow and describe its trigger, finish point, participants and troublesome exceptions. Add a baseline that can be observed, such as elapsed days or the number of handovers requiring a chase. Do not promise a productivity gain before measurement.

Turn that account into five outcomes at most. Phrase each from a user's view: an approver finds the evidence behind a request without asking the submitter to resend it.

The Technology Code of Practice asks government buyers to define user needs and weigh accessibility, security, privacy, integration and purchasing. Borrow its breadth, keep the project's context visible.

Separate gates from scores

A gate has a binary consequence. Examples include an essential export, support for a required access method or a security control set by the organisation's risk owner. Write the acceptance evidence beside the gate. Marketing language should not count as proof.

Use weights only for negotiable differences. One workable model is:

These figures are a hypothetical allocation, not a universal benchmark. Change them before seeing vendor results and document who approved the change. Otherwise, weights can be adjusted to rationalise a favourite candidate.

Run the same evidence exercise

Give each supplier identical sample records and two scenarios: the normal path and an exception. Ask for a live demonstration, then let intended users repeat critical steps in a controlled trial if one is available. Record the plan, configuration, date and person observing.

Score the evidence, not the confidence of the presentation. Mark each response as observed, documented, supplier-stated or unresolved. The NCSC says confidence in a cloud provider should reflect the impact of disclosure, corruption or unavailability, and distinguishes simple assertions from stronger independent assurance in its provider assessment guidance.

Check the edges of the service

Open a sample export outside the product. Trace one integration failure and one leaver through the proposed process. Ask who owns administrator access, incident escalation and recovery. These edge cases reveal operating effort that a feature score misses.

If personal data will be processed, send the proposed use to the relevant privacy reviewer. The ICO says controllers must select processors offering sufficient guarantees and keep their performance under review in its controller responsibilities page. That guidance is currently marked for review, so confirm the live position before contracting.

Make the decision readable

The final record should show failed gates, weighted totals, unresolved points, total-cost assumptions and reviewer conditions. Include a short dissent note if users and commercial reviewers reach different conclusions. A score is a prompt for judgement, not an automatic award.

Set an expiry date. Supplier terms, product functions and internal needs change. The next action is to build the two test scenarios before contacting a vendor; they will sharpen both the demonstration and the eventual acceptance plan.

Before you act

Common questions

How should gates differ from scores?

A gate has a binary consequence, such as an essential export, a required access method or a security control set by the risk owner. Scores apply only to negotiable differences. Write the acceptance evidence beside each gate, and do not treat marketing language as proof.

What evidence should suppliers provide?

Give each supplier identical sample records and two scenarios, the normal path and an exception. Ask for a live demonstration, then let intended users repeat critical steps in a controlled trial. Record the plan, configuration, date and observer, and mark each response as observed, documented, supplier-stated or unresolved.

What should the final decision record contain?

It should show failed gates, weighted totals, unresolved points, total-cost assumptions and reviewer conditions. Include a short dissent note if users and commercial reviewers disagree. A score prompts judgement rather than an automatic award, and the record should carry an expiry date.