A department head decides that a spreadsheet has had its time and asks three suppliers for a quote. The request is two paragraphs long. The quotes come back with different scopes, different assumptions and a spread that nobody can explain. The meeting that follows is about what each supplier imagined, not about which one is better.
This article is for a manager who orders software for their own team and has to ask for quotes. It shows how to write a one-page brief first. The page does not replace a detailed specification, and it is not a contract. Its job is to make sure every supplier reads the same problem. Once the quotes arrive, our article on reading a software quote helps you compare them. If you need a longer document later, see what a good software requirements document contains.
Why one page
A long document is rarely read in full by the people who price the work. A single page forces you to choose what matters, and it is short enough that you can ask a colleague to read it in five minutes and tell you what they understood. If they cannot say in one sentence what the software is for, a supplier will not be able to either.
The six sections
1. The problem. Describe what happens today, in a few sentences, without naming a solution. "Orders are copied by hand from emails into a spreadsheet, which takes two people about a day each week and produces errors in delivery dates" is a problem. "We need a portal" is a solution. Suppliers can propose better solutions than the one you imagined, but only if they see the real problem.
2. The users. List who will use the software, roughly how many of them there are, and how often. Separate people who work in it every day from people who only look at a result once a month. A system for five daily users and one for fifty occasional ones are different projects.
3. The scope. List what the first version must do, as a short set of statements, each starting with a verb: record an order, assign it to a person, show open orders by date. Aim for five to ten lines. If you have twenty, you are describing the final system, not the first version.
4. What is out of scope. Write down what you are deliberately not asking for now, such as a mobile app, reporting for management or integration with the accounting tool. This section looks optional and is not. A supplier who sees no exclusions will either price everything cautiously or assume less than you expect, and both lead to an argument later.
5. The data. Say what data the software will use, where it is today, roughly how much of it there is and who owns it. Mention whether it has to be moved from an old tool and whether it contains personal data. Data surprises are among the most common reasons for delays, so even a rough description helps.
6. The acceptance criterion. Write one sentence that tells you the work is done. It should be something a colleague could check without the supplier in the room. For example: "A person who has not seen the system can enter ten real orders from last week's emails, and the weekly overview shows the same totals as the current spreadsheet." Avoid criteria such as "the system is fast and easy to use", which nobody can test.
A short example
Here is how a brief might look for a small operations team. It is invented for illustration and describes no real company.
Problem. Our team of six receives service requests by email and tracks them in a shared spreadsheet. Requests get lost, and nobody can say quickly which ones are overdue. Users. Six people use it daily. Two managers look at an overview once a week. Scope. Record a request with a due date. Assign it to a person. Mark it done. Show open requests sorted by due date. Send the assignee an email when a request is assigned. Out of scope. Customer access, mobile app, invoicing, reports beyond the open list. Data. About 1,200 requests from the last two years in one spreadsheet. We want to import the open ones. No special personal data beyond names and business email addresses. Acceptance. A team member enters five real requests, assigns them, and closes two. The open list shows the other three in due-date order.
That page takes about half an hour to write. A supplier can read it, ask three sharp questions and give you a quote that matches what you meant.
What to add around the page
Keep the brief to one page, but send a few lines with it. Say when you need quotes, who will make the decision and whether you have a rough budget range. A range is not a weakness. It lets a supplier tell you honestly what fits and what does not. Ask each supplier to list the assumptions behind their price, so you can see where they read the page differently.
Common mistakes
- Describing the solution instead of the problem. You limit the supplier and may pay for something you do not need.
- Listing every wish. The first version should be small enough to finish and use.
- Leaving out the exclusions. What is not written is assumed differently by each side.
- Forgetting the people who will use it. Ask one or two of them to read the page before it goes out.
- Writing a criterion nobody can check. If you cannot test it, it will not end a discussion.
What to do this week
Write the six sections in an hour, with the problem first. Give the page to one colleague who works with the process and one who does not, and ask each what they think will be built. Change the page until their answers match yours, and only then send it to suppliers.
Sources
- Our related articles linked above.
- The brief structure is a general working approach and the example is invented; it does not describe a particular company, system or supplier.