The short version
Six things: what happens now, what it costs you, where the data lives including the awkward part, what you have already tried, what “working” would mean, and any constraint that cannot move. Leave the solution open. The divergence between how different practitioners read the same problem is the most useful information you will get.
What happens today
In concrete terms. Not “our finance process is inefficient” but “three people spend roughly two days a week matching supplier invoices against purchase orders and delivery notes, and we close the month four days late”.
Specificity does two jobs. It lets a practitioner size the work, and it filters — anyone who responds to that with a generic capabilities deck has told you something useful about themselves.
What it costs you
Hours, errors, delay, or lost revenue. This is the number that decides whether the project is worth doing at all, and it is yours to supply because only you can measure it.
It also protects you. A quote well above the annual cost of the problem is easy to decline when the annual cost is written down in front of you.
Where the data lives — including the awkward part
Name the systems. Then name the difficult one explicitly: the tool with no API, the PDFs arriving by email, the spreadsheet that is the real source of truth, the platform only a vendor can change.
This is the single highest-value paragraph in any brief. Integration is usually the largest cost, and a constraint discovered in week three often invalidates the whole plan. Saying it up front changes the proposals you get, and occasionally it changes them to “this is not viable, here is why” — which is worth knowing before you pay for it.
What you have already tried
Most businesses have attempted something. Per-supplier OCR templating, an off-the-shelf tool, a pilot that never left the pilot stage. Say what it was and why it did not hold.
This prevents the obvious suggestion arriving as though it were novel, and it tells a practitioner where the real difficulty is. “Templating worked for our top twenty suppliers and failed on the long tail” is a more precise specification than most requirement documents.
What would “working” mean?
The threshold at which you would trust it, and what should happen to everything below that threshold. “Correct on 95% of invoices with the rest routed to a person” is a specification you can accept or reject. “Automates invoice processing” is an argument waiting to happen after delivery.
If you genuinely do not know what threshold would satisfy you, say that too — it is a legitimate thing to work out during discovery, and admitting it is better than inventing a number you will not defend.
What cannot move
Data residency. A regulator who must approve changes. A system you are contractually barred from touching. A go-live date tied to something external. A prohibition on data leaving your tenancy.
Constraints stated up front cost you nothing. Constraints discovered late cost you the project.
What to leave out
The solution. Naming the technology, the model, the architecture or the vendor forecloses the answer and guarantees you will not hear the better idea, if there is one.
Also leave out your budget, at least initially. Not to be adversarial — but the annual cost of the problem, which you should include, is a more useful anchor and it lets you see how each practitioner sizes the work independently.
How many people should I send it to?
More than one, and read the responses for divergence rather than price. Different practitioners will read the same brief differently: one proposes a rules engine with a model for exceptions, another an agent with a human approval step, a third says fix the upstream data first.
That disagreement is the most valuable output of the whole exercise. It shows you the actual solution space, which is something no single proposal can, and it is usually worth more than the price comparison people think they are running.
How long should the brief be?
One to two pages. Long enough to cover the six things above with specifics, short enough that a practitioner reads all of it before responding.
Twenty-page requirement documents get skimmed, and they usually contain a great deal of context and very little of the information that determines feasibility. If you find yourself writing at length, check whether you are describing the process or justifying the project internally — the second is a different document for a different audience.
Should I include a budget?
Include the annual cost of the problem rather than the budget. It anchors the conversation on value and lets you see how each practitioner sizes the work independently, which is information a stated budget destroys — quote a number and most proposals will arrive close to it.
The exception is a hard ceiling. If there is genuinely no more than a fixed amount available, saying so early saves everyone the time of a proposal you cannot accept.
What if I don't know what's technically possible?
That is the normal case and it is not a problem, because describing the process rather than the solution is exactly what protects you from it. You do not need to know what is possible — you need to describe the work accurately enough that someone who does can tell you.
The failure mode is the opposite: reading about a capability, assuming it maps onto your situation, and writing a brief that asks for it. That produces quotes for the thing you named rather than answers to the problem you have.
What does a good response look like?
It asks questions before it proposes anything. It states assumptions explicitly. It proposes discovery before a build if the scope genuinely cannot be known yet. It names a measurable definition of working. And it mentions at least one thing that might not work.
A response that quotes a fixed price with total confidence and no questions is not evidence of expertise. It is evidence that nobody has looked at your data.
Who should write it?
Whoever understands the process, with about twenty minutes from whoever understands the systems. It does not need to be written by a technical person, and briefs written by someone remote from the work tend to describe the org chart rather than the task.
The most useful single input is the person who does the job today. They know the exception rules, the workaround everyone uses, and which system is genuinely awful. That knowledge is what makes a brief specific, and it is almost never in the requirements document.