How to write a software tender brief that gets better answers

Why most software tender briefs get weak answers

A software tender brief gets better answers when it describes your problem, your users and your rules clearly enough that suppliers can respond to the same question in the same way. Vague briefs produce glossy brochures. Clear briefs produce answers you can actually compare.

Most weak briefs fail in predictable ways. They list features copied from a competitor's website. They hide the budget. They ask "Is your system secure?" instead of asking for evidence. And they never say how responses will be scored, so every supplier guesses differently.

This guide walks through the sections a good brief needs, using UK guidance from government, the Information Commissioner's Office and the National Cyber Security Centre. It applies whether you are a small business choosing a new CRM system, a charity replacing its database, or a public body running a formal procurement.

1. Start with the problem, not the product

Open your brief with the problem you need solved, not the solution you imagine. The UK government's Technology Code of Practice puts "define user needs" first for exactly this reason: buying technology before understanding the need is how organisations end up with expensive systems nobody uses.

A useful problem statement answers three questions:

• What is going wrong today? For example: "Field staff spend around 40 minutes a day re-keying paper job sheets, and managers cannot see job progress in real time."
• Who is affected? Name the roles, not just the department.
• What does success look like in 12 months? Use measurable outcomes, such as fewer missed appointments or invoices sent within two days of a job.

The GOV.UK Service Manual advises always starting a service by learning about the people who will use it. Even two or three short conversations with frontline staff will sharpen your brief more than a long feature wishlist.

When suppliers understand the outcome, they can propose approaches you had not considered. When they only see a feature list, they tick boxes.

2. Describe your users, scale and current systems

Suppliers cannot price or design accurately without knowing your size and setup. Give them the numbers up front, even if they are estimates.

• Number of sites: for example, 3 offices and a team of mobile field staff.
• Users by role: for example, 150 field staff, 30 office staff, 8 managers and 3 IT staff.
• Devices: for example, shared Android tablets in vans and Windows laptops for managers.
• Connectivity: for example, patchy mobile signal in rural areas and slow Wi-Fi in one older building.
• Current systems: for example, paper job sheets, spreadsheet rotas and separate accounting software.
• Integrations needed: for example, a payroll export and a link to your accounting system.
• Data to migrate: for example, 3 years of customer records and job history.

Be honest about the messy parts. If staff have low digital confidence or Wi-Fi is unreliable, say so. Good suppliers will explain how they handle offline working and training. Poor fits will reveal themselves early.

If your service must be usable by people with disabilities, ask for conformance with WCAG 2.2 at level AA. Public sector bodies have a legal duty here under the accessibility regulations described on GOV.UK.

3. Separate must-haves from nice-to-haves

A brief where every requirement is "essential" tells suppliers nothing about your priorities. Rank your requirements so suppliers know where to focus and you know what you can trade away.

Many teams use MoSCoW prioritisation, a method popularised by the Agile Business Consortium in its DSDM framework:

• Must have: without it, the system is unusable or unlawful for you.
• Should have: important, but a workaround exists.
• Could have: desirable if budget and time allow.
• Won't have (this time): explicitly out of scope, which stops suppliers padding their bids.

Write each requirement as a testable statement. "The system must be easy to use" cannot be tested. "A new starter must be able to log a completed job after a 30-minute induction" can be demonstrated in a supplier session.

Keep the must-have list short. If it runs past 15 or 20 items, some of them are probably "shoulds".

4. Set out data protection, security and compliance requirements

If the software will hold personal data, your brief must say so and ask suppliers to show how they meet UK law. Ask for evidence, not assurances.

UK GDPR. A software supplier that stores or processes personal data on your behalf usually acts as a processor. The ICO's guidance on contracts says a written contract must be in place whenever a controller uses a processor, and the UK GDPR sets out what it must contain. If the system will hold special category data, such as health records, or personal data on a large scale, you will likely need a Data Protection Impact Assessment before go-live. Ask suppliers for a sample data processing agreement, where data is hosted, and how they support subject access requests.

Cyber security. Ask whether the supplier holds Cyber Essentials or Cyber Essentials Plus, the government-backed scheme overseen by the National Cyber Security Centre. The NCSC's 12 principles of supply chain security are a good basis for further questions about access controls, incident response and subcontractors.

Sector-specific rules. Some sectors add their own requirements, so name any that apply to you and ask suppliers which they already meet. In health and social care, for example, organisations with access to NHS patient data and systems must use the Data Security and Protection Toolkit, and NHS England keeps an assured solutions list of digital social care record systems, with GOV.UK guidance on choosing one.

Exit and portability. Ask how you will get your data back, in what format, and at what cost if you leave. The Technology Code of Practice encourages open standards so systems can be upgraded and replaced. This question is far easier to settle before signing than after.

5. Be clear about budget, timeline and procurement route

Share a budget range. Hiding it rarely saves money; it wastes suppliers' time and yours on proposals that were never affordable. A range such as "£15,000–£25,000 per year including licences and support" lets suppliers shape a realistic offer.

Give a timeline with fixed dates:

1. Brief published
2. Deadline for clarification questions
3. Response deadline
4. Shortlist demonstrations
5. Decision and contract award
6. Target go-live

If you are a public body, your procurement route matters. The Procurement Act 2023 came into force on 24 February 2025, replacing the Public Contracts Regulations 2015 for procurements started from that date. It introduced the "most advantageous tender" test and a new competitive flexible procedure, and notices are published through the Central Digital Platform on Find a Tender. The government's Procurement Act 2023 guidance explains the procedures in detail. Devolved Scottish authorities follow Scotland's own procurement rules instead.

You may also be able to buy through a framework such as G-Cloud, run by the Government Commercial Agency. The agency replaced the Crown Commercial Service on 1 April 2026.

If you are a private business or charity, you are not bound by these rules. Borrowing their discipline still helps: publish the same information to every supplier, answer clarification questions for everyone, and keep a record of your decision.

6. Explain how you will evaluate answers

Tell suppliers exactly how you will score their responses. When suppliers know the weighting, they put effort where it counts and you get answers that line up side by side.

Under the Procurement Act 2023, public bodies must set out their award criteria and their relative importance in advance (section 23). Private buyers have no such duty, but the same transparency produces better bids.

An example weighting for a typical business software tender:

• Fit with must-have requirements: 35%
• Usability for frontline staff (scored at demo): 20%
• Total cost over 3 years: 20%
• Security, data protection and compliance: 15%
• Implementation, training and support: 10%

Publish your scoring scale too, for example 0 (no evidence) to 5 (fully meets with strong evidence). Score independently with at least two people before agreeing a final mark. This reduces the risk of one enthusiastic demo swaying the decision.

7. Ask questions that reveal real capability

Yes/no questions invite yes. Open, scenario-based questions force suppliers to show how their software actually works.

• Instead of "Do you support offline working?", ask: "A field engineer loses signal mid-job. Walk us through what happens to the notes they are typing."
• Instead of "Is your system secure?", ask: "Provide your current Cyber Essentials certificate and describe your last security incident and how you responded."
• Instead of "Do you offer training?", ask: "Describe your training plan for 190 staff across three offices, including part-time and remote staff."
• Instead of "Can you integrate with payroll?", ask: "Name two customers using your payroll export with our payroll provider."
• Instead of "Is your pricing competitive?", ask: "Give a fully itemised 3-year cost, including set-up, migration, licences and support."

Set word limits for each answer, such as 300 words. Limits stop suppliers burying weak points in long marketing copy, and they make scoring faster.

Finally, ask for references from organisations similar to yours in size and sector, and actually call them.

Software tender brief checklist

Before you publish your software tender brief, check that it includes:

• A clear problem statement and measurable outcomes
• Users by role, number of sites, devices and connectivity
• Current systems, required integrations and data to migrate
• Requirements ranked as must, should, could and won't
• UK GDPR, security and sector compliance requirements, with evidence requested
• Exit and data portability terms
• A budget range and fixed timeline
• Published evaluation criteria, weightings and scoring scale
• Open, scenario-based questions with word limits
• A request for comparable references

A good brief takes a few extra days to write, but it saves weeks of chasing unclear proposals and reduces the risk of choosing the wrong system. If you would like help shaping your brief or comparing supplier responses, contact Careomat.

Sources

1. Government Digital Service, The Technology Code of Practice, GOV.UK.
2. Government Digital Service, Learning about users and their needs, GOV.UK Service Manual.
3. W3C, Web Content Accessibility Guidelines (WCAG) 2.2.
4. Government Digital Service, Understanding accessibility requirements for public sector bodies, GOV.UK.
5. Agile Business Consortium, DSDM and MoSCoW prioritisation.
6. Information Commissioner's Office, Contracts, Guide to accountability and governance.
7. National Cyber Security Centre, Cyber Essentials overview.
8. National Cyber Security Centre, 12 principles of supply chain security.
9. NHS England, Data Security and Protection Toolkit information standard.
10. NHS England, Assured solutions for digital social care records.
11. GOV.UK, Digital social care records: choosing and implementing solutions.
12. legislation.gov.uk, Procurement Act 2023.
13. legislation.gov.uk, Procurement Act 2023, section 23: Award criteria.
14. Cabinet Office, Procurement Act 2023 guidance documents, GOV.UK.
15. Cabinet Office, Find a Tender service.
16. DWF, Procurement portal: application of the Procurement Act 2023 in Scotland.
17. Government Commercial Agency, Crown Commercial Service (CCS).

Sources checked on 15 October 2026.