Most briefs we receive are either a paragraph or a hundred-page specification, and both make accurate quoting difficult. The paragraph forces every supplier to invent a different project and price that. The specification usually details the wrong things at enormous length, having decided the solution before anyone examined the problem.

What works is a document of five to ten pages that is specific about the problem, the constraints and the definition of success, and deliberately open about the implementation. Here is what to put in it.

Start with the situation, not the request

Describe how the work is done today, including the workarounds. "Orders arrive by email, one person retypes them into the warehouse system and a spreadsheet, and the spreadsheet is the real source of truth" is worth more than any feature list, because it tells a supplier where the value is and where the risk is hiding.

Include volumes and the shape of them: how many of the thing per day, at peak, and how that has changed. A system for fifty orders a day and one for fifty thousand are different systems.

Say who will use it, and how

List the distinct kinds of user and what each needs to do. Note where they are and on what — a warehouse team on phones with gloves on has different requirements from an office team on two monitors.

This section quietly determines a large part of the cost, because it is where roles, permissions and the number of interfaces are decided.

List the systems it must talk to

Name them, with versions, and say what you know about access: whether there is an API, whether anyone has credentials, who owns the relationship with the vendor.

This is the section that most often changes an estimate after the fact. A supplier who learns in week three that the integration is a nightly file drop rather than a real API will be revising something, and it will not be in your favour.

State the constraints honestly

  • Budget, or at least a range. Withholding it does not get you a better price; it gets you proposals aimed at the wrong project. A supplier who knows the budget can tell you what is achievable within it, which is the conversation you actually want.
  • Deadline, and what it is tied to. "Before the trade fair in May" is a real constraint that shapes scope. "As soon as possible" is not.
  • Non-negotiables: data that may not leave the country, a platform you are committed to, a security review you must pass, an accessibility standard you are obliged to meet.

Define success so it can be checked

Write down what will be true if this works. "Order processing takes under thirty minutes end to end", "the monthly report is produced without manual consolidation", "the error rate on data entry falls below one per cent".

These sentences do more work than anything else in the brief. They let a supplier propose a cheaper way to reach the same outcome, and they give both sides an agreed measure at the end that is not a matter of opinion.

Separate what you need from what you want

Split requirements into three groups: must have for launch, should have soon, could have eventually. Do it before you send the brief, because if you do not, the split will be made under time pressure later, by whoever is in the room.

A brief where everything is essential tells a supplier that the priorities have not been decided, and the quote will carry a margin for that.

Leave the solution to the people you are asking

Say what the system must achieve, not which framework it should use or how the database should be arranged. You are paying for that judgement, and constraining it in advance removes the option of a supplier telling you the useful thing: that half of what you asked for is unnecessary, or that an existing product does most of it.

The exception is genuine constraints — an existing platform you must extend, a technology your own team maintains. Those belong in the brief, stated as what they are.

What to expect back

A serious response asks questions before it prices, and the questions are the signal. Suppliers who ask about data quality, edge cases and what happens when an integration is unavailable have built systems like yours. Suppliers who return a figure and a timeline from the brief alone have not read it closely enough.

Expect the proposal to include assumptions, a scope of what is not included, and a statement of how change will be handled. Any of the three missing is a gap that will be filled by argument later.