For Australian owners and ops managers about to go to market

How to Write an AI Project Brief That Gets Honest, Comparable Quotes

Most AI projects go to market on a paragraph that says the business wants to use AI to improve efficiency. Three vendors read it, imagine three different projects, and send back three prices that cannot be compared, because they are not for the same thing. The fix is not a longer document. It is a brief that states the problem, the volumes, the systems, the constraints and the number that defines success, so every response answers the same question.

This page gives you the structure section by section, the questions a competent vendor should ask you back, and the red flags to watch for in a response. Use it with us or use it with somebody else. It works either way.

Book a Scoping Call (03) 9003 0111

Realistic ROI

3 to 6 pages

The length that gets read

Long enough to be specific about volumes and systems, short enough that every vendor reads all of it before quoting

Same 10 headings

Answers you can line up

When every response follows one structure, a price difference means something instead of hiding a scope difference

One number

An agreed definition of success

A single measurable outcome with a baseline you can point at today, written down before anybody quotes

2 to 6 weeks

Typical SME build once scope is fixed

Realistic when the brief pins the scope down, open ended when it does not

Why Yes AI Publishes This Instead of Keeping It Quiet

We sell scoping and build work, so handing you the structure that makes vendors compete on identical ground looks like an odd move. It is not. Vague briefs produce projects that fail slowly, and one failed AI project sours a business on the idea for years, including on the work that would have paid for itself. We would rather quote against a hard brief and lose than win something that was never really defined. Four reasons the effort is yours to gain from.

A vague brief hands all the risk to you

When the brief does not define the work, the vendor prices the risk of not knowing, then protects themselves with assumptions buried on page four. You either pay a padded fixed price, or you sign a low number that turns into variations the moment reality arrives in week three. Every hour you spend making the brief specific comes straight off the contingency somebody was otherwise going to charge you for the ambiguity.

Comparable quotes need identical questions

Three vendors reading three different projects out of the same paragraph will send three prices, and putting them side by side is meaningless. If your brief sets the same headings, the same volumes and the same success measure for everyone, the responses line up. Where they then differ, you are looking at a real difference in approach or risk appetite, not a difference in what each vendor imagined you meant.

The brief becomes the statement of work

Whatever you write is the document both sides reach for when there is a disagreement in week five about whether that report was in scope. Write it as though it will be an attachment to the contract, because in most engagements worth doing that is exactly what happens to it. It is also why the out of scope section earns its place. Naming what you are not asking for protects the vendor as much as it protects you.

Good vendors want a hard brief

A specific brief is not adversarial, it is a filter. The people who can actually do the work are relieved to see volumes, systems and constraints in writing, and they come back with sharper questions. The ones who were going to sell you a demo and work the rest out later go quiet, or send a proposal that answers a different question. That reaction alone is worth the fortnight it takes to write.

The Ten Sections of a Brief That Works

The six blocks below carry all ten headings. Keep them in this order, because it moves from what happens in your business today, through what has to be true, to how you will decide. Write it in plain language. No vendor worth hiring needs you to know the technical vocabulary, and using it wrongly costs you more than not using it at all.

Section 1

The problem in one paragraph, not the solution

Describe what is going wrong for the business in the words you would use to a colleague. Who is affected, how often it happens, and what it costs in hours, money, errors or work you cannot take on. Do not name a technology and do not describe a chatbot, an agent or a dashboard, because the moment you do, every response is a quote for that thing rather than for your problem. If the honest answer turns out to be a better form, a setting in software you already pay for, or two hours of training, a good vendor has to be free to say so.

Sections 2 and 3

The current process, end to end, with volumes

Walk the process from the first trigger to the last action. Name the role at each step, what they open, what they type, what they decide, and what they do when it goes wrong. Then attach real numbers: how many a day or a week, how long each one takes, how many need reworking, what a peak looks like, and how far the awkward cases sit from the routine ones. This is where quotes stop being guesses. It is also the section people write from memory, which is why the numbers in it so often change once somebody actually counts.

Sections 4 and 5

Systems, data and who can grant access

List every system by name and version: the accounting package, the CRM, the job or practice management software, Microsoft 365 or Google Workspace, the shared drive, the mailbox everything lands in. For each one, say who inside your business can approve access, whether other software can connect to it, and whether your software vendor charges extra for that connection or gates it behind a higher plan. Then say where the data lives and who owns it. This section decides your timeline far more often than the build does, because waiting on a third party to switch an integration on is one of the most common delays in an AI project.

Section 6

Success as one measurable number

Write the sentence: this project has worked if X moves from A to B by date C. Hours per week handed back to the team, a response time that drops, a share of enquiries resolved without a person, a backlog cleared and kept clear. Include the baseline as it stands today and say how you measured it, because a target with no baseline cannot be proved either way and both sides will remember it differently in six months. If you cannot measure it today, that measurement is the first piece of work and it belongs in the brief as such.

Sections 7 and 8

Out of scope, and the constraints that will not move

Be explicit about what you are not asking for, especially the adjacent things a vendor may assume: the other branches, the other department, migrating historical records, replacing the software you keep complaining about. Then the hard constraints. Personal or health information that must stay in Australia or must never leave a named system, records you have to retain, decisions a qualified person must sign, security requirements imposed by your insurer or your largest customer, and any obligations under the Privacy Act and the Australian Privacy Principles that apply to your business. This page is general information rather than legal advice, so confirm which obligations actually bind you with your own adviser and write those into the brief. Constraints do not scare off good vendors. Discovering them in week six does.

Sections 9 and 10

Budget range, dates, and how you will decide

State a budget range in AUD and say what it covers, build only or build plus a year of support and changes. Give the timeline honestly, including any hard date and what is driving it, an audit, a season, a lease or a contract ending. Then tell vendors how you will evaluate: the criteria, roughly how you weight them, who sits on the panel, when you will decide, and whether there will be a question round. Publishing the criteria is what stops the decision quietly drifting to whoever presented best on the day.

Six Vague Brief Lines and What They Should Have Said

Task	Traditional	With a Yes AI Brief	Notes
Wholesaler drowning in emailed purchase orders	We want AI to process our orders automatically	Roughly 150 emailed orders a week across about 15 customer formats, two staff keying them into MYOB, about 6 minutes each, rework rate not currently measured	The number of different formats prices this job, not the order count. Fifteen layouts is a very different build from two, and no vendor can tell which you have from the vague version.
Clinic wanting the phone covered after hours	We want an AI receptionist	About 70 calls a week outside opening hours, most are booking or rescheduling, bookings live in our practice software, no clinical advice ever, anything else transfers to the on call mobile	Naming the practice software and the one thing the system must never do moves the quote more than the call volume does. Health information also pulls privacy obligations squarely into scope.
Construction firm that cannot find the current revision	We want AI search across our documents	Tens of thousands of files across a shared drive and Microsoft 365, 12 site supervisors, and the question is almost always which revision of a drawing or specification is current	Whether every answer must cite the source file and its revision is one of the biggest drivers of cost here, and of whether anyone on site will trust the result enough to use it.
Accounting practice buried in routine client email	We want AI to write our client emails	About 200 routine client emails a week in four repeatable categories, drafted for a person to review and send, never sent automatically, tone matched to our existing letters	Draft for review and send automatically are two different projects with different risk, different review effort and different prices. Say which one you actually mean.
NDIS provider losing evenings to progress notes	We want AI to do our reporting	About 30 support workers writing notes after each shift, data must stay in Australia, participant consent position stated, output must be editable and signed by the worker before submission	Data location, consent and who signs are constraints rather than features. Put them in the brief and the compliant approaches rise to the top without you having to police it.
Online retailer with a support inbox that never empties	We want a chatbot on the website	Roughly 700 enquiries a month, well over half are where is my order, orders sit in Shopify, target is to resolve order status without a person and route the rest with the history attached	Splitting the volume into what can be answered from a system of record and what genuinely needs a person is the difference between a quote and a guess.

Six Honest Warnings Before You Send It

Briefing the solution quietly rules out the better answer

The moment the brief says chatbot, agent or dashboard, every response is narrowed to that shape and you will never hear that a setting in software you already pay for, a redesigned form, or removing one approval step would have fixed most of it for nothing. Describe the problem and the outcome, and explicitly invite vendors to disagree with the solution you had in mind. A vendor who does disagree, and explains why in language you can follow, is showing you something useful about how they will behave when the project gets hard.

The volumes you write from memory will be wrong

Most briefs we read overstate the exceptions and understate the routine work, because people remember the awful cases and forget the hundred easy ones. Go and count before you write a number. Export a month from the mailbox, the job system or the phone log, then sit with a stopwatch and time twenty real cases including a few bad ones. Volumes that turn out well above what the brief claimed are a common reason a fixed price becomes a variation, and you are the one who pays for that, not the vendor.

Access to your own data is usually the critical path

The build is rarely what holds a project up. What holds it up is waiting on a software vendor to enable a connection, discovering that the connection sits behind a higher plan or a per connection fee, chasing an administrator login that left with a staff member, or joining the back of an IT provider queue. Name in the brief who can approve access to each system, and start those conversations while you are still choosing a vendor. Every week you save here is a week off the delivery date and it costs you nothing.

AI will not fix a broken process, it will run it faster

If the approval step is skipped half the time, the data is entered three different ways, or two teams keep separate versions of the truth, automating on top of that hides the problem and makes it harder to see. Fix the process or at minimum document it honestly first. Sometimes the most valuable outcome of writing a brief is realising the project you needed was a process change and an afternoon of training. That is a good result, not a wasted fortnight, and it is far cheaper than discovering it after the build.

An accuracy target you cannot measure is theatre

Ask three vendors for ninety nine per cent accuracy and all three will agree, because none of you have defined what counts as correct or on what sample. Define it: which field or decision, judged by whom, across how many cases, over what period, and what happens when it is wrong. Then be equally clear about the work that should never run unsupervised whatever the number says. Anything that sends money, commits you contractually, gives clinical, legal or financial advice, or cannot be reversed needs a person in the loop, and your brief should say so rather than assume it.

Do not let an AI tool supply the facts in the brief

Ask a general AI assistant to write this for you and it will hand back six confident, well organised pages containing volumes it made up, a process that sounds like every other business in your industry, and constraints nobody in your building has confirmed. Vendors notice quickly, because the specifics quietly contradict each other and no number has a source. It is genuinely useful for tidying your wording, imposing structure on what you already know, and firing questions at your draft that you had not thought to ask. It cannot supply the counts, the system names, the person who can approve access, or the condition your insurer imposed. Those only exist inside your business, and they are the whole reason the brief is worth reading.

How Yes AI Helps, Whoever Ends Up Building It

We will help you write the brief

A short working session with the people who actually do the work, and you leave with the document in your own words, ready to send to whoever you like. You own it. If you then run a fair process and somebody else wins on merit, that is a reasonable outcome and the market gets a little better for it.

Process mapping and a real baseline

If you cannot put numbers next to the process, we count it with you. Sample the volumes, time the steps, pull the exports, and separate the routine cases from the genuine exceptions. You end up with a baseline that survives contact with a vendor, and the same baseline is what later proves whether the project worked or not.

A second read on the responses

Send us the proposals and we will show you where they are not comparing like with like, which assumptions are load bearing, what is missing on data ownership, hosting, support and change, and which questions to put back to each vendor before you decide. If we have also quoted, we say so plainly and step out of that comparison.

Scoping and building it, if you want us to

If you do want us in the running, we scope properly first: discovery, then a fixed scope, price and timeframe before any build starts. Consulting engagements start at $1,000 for a focused BASIC piece, $3,000 for a STANDARD engagement and $10,000 for a STRATEGIC one across a broader estate. One Australian team then designs, builds, integrates and supports it.

Taking Your Brief to Market

Five steps from a rough idea to a signed scope of work. For most Australian SMEs the whole exercise runs three to six weeks, and the counting in step one is what makes the other four steps fast.

Count before you write

Spend two or three days on the numbers. Export a month of the emails, jobs, calls or orders involved, time twenty real cases end to end, and note how many were straightforward against how many were awkward. Write down who does each step and what they do when something unusual turns up. It is the least glamorous step in the process and the one that changes your quotes the most.

Write the brief

Three to six pages under the ten headings: problem, current process, volumes, systems, access and data, success measure, out of scope, constraints, budget and timeline, evaluation. Plain language throughout, no technical vocabulary you would not use out loud. Then have one person who does the work read it and mark everything that is not how it really happens, because some of it will not be.

Shortlist and send it to three

Three vendors is enough to see a genuine spread and few enough that you will read every response properly. Send all three exactly the same document on the same day, give them the same deadline, and name one person to take questions. Share every question and its answer with all three. It keeps the process fair and it usually improves the brief for everybody, including you.

Run a question round, then score

Expect questions and welcome them. Update the brief wherever a question exposes a gap, reissue it to everyone, then score the responses against the criteria you published rather than against how much you enjoyed the meeting. Score the assumptions and exclusions as carefully as the price, because that is usually where the two cheap proposals differ from the expensive one.

Award, and turn the brief into the scope of work

Attach the brief and the winning response to the contract, with the assumptions and exclusions written into the scope rather than left sitting in an email thread. Agree the success measure, the baseline, the review date and what happens if the number is not met. Then keep the brief current, because it is the document you will pick up when you extend the work next year.

FAQ

Why is "we want to use AI" not a brief?

Because it does not describe anything a person could price. AI is not one thing, it is a wide set of capabilities with very different costs, risks and timeframes, so a vendor reading that line has to invent a project in order to quote at all. Every vendor invents a different one, which is why the prices come back incomparable and none of them are quite for your problem. Write the problem instead: who is affected, how often, what it costs you today, and what would have to be true for it to be considered fixed. Choosing the technology is the job of whoever you hire, and their argument for it is one of the things you are evaluating.

How long should the brief be?

Three to six pages for a typical Australian SME project. That is long enough to carry the volumes, the systems, the constraints and the success measure, and short enough that every vendor reads all of it rather than skimming. Twenty pages of background gets skimmed and the one line that mattered gets missed. A single paragraph gets you guesswork dressed up as a quote. If you have supporting material such as a process diagram, a handful of sample documents with the personal details removed, or a report export, attach it as an appendix rather than swelling the body of the brief.

Should we really put a budget range in it?

Yes, and this is the section people resist hardest. A range does not get you overcharged, because a competent vendor is pricing the work and you are about to compare three of them anyway. What it does is let each vendor shape a proposal that fits you. At the lower end they will propose the tightest first slice that still delivers something real, at the higher end the fuller build. Without a range you routinely receive one proposal at ten times your budget and one so thin it cannot work, and you have burned a fortnight finding that out. Say what the range covers as well, build only or build plus a year of support and changes.

What should a competent vendor ask us after reading it?

Expect questions along these lines. What happens today when the process fails, and how often is that. Who owns the decision when the system gets something wrong. What does correct actually mean for this task and who judges it. Can we see twenty real examples including the awkward ones. Who inside your business can approve access to that system, and does your software vendor charge for the connection. What have you already tried and why did it stop. What is driving the deadline. Who else has to say yes before this can proceed. Which of your constraints are legal or contractual and which are preferences. If nobody asks anything resembling that before quoting, you are being sent a template.

What are the red flags in a response?

A price with no assumptions or exclusions listed. No questions asked before quoting. A proposal that restates your problem as a licence for the vendor platform. Silence on who owns the data and the resulting code, and on where it will be hosted. No monitoring, support or change path after go live. A demo that never touches your data. A timeline with no dependency on you providing access, which tells you the hardest scheduling problem has not been thought about. Case studies that cannot be named or checked. And any specific accuracy figure promised before anyone has looked at your actual records.

Do we need to know what technology we want?

No, and it is usually better not to commit to one. Your job is to describe the problem, the constraints and what success looks like. The vendor job is to propose an approach and justify it in language you can follow, including why they did not choose the obvious alternative. If a proposal cannot explain in plain English why this approach suits your volumes, your data and your risk, that tells you something about the vendor rather than about the technology. Do state genuine technical constraints though, such as software you must keep, systems you cannot touch, or data that has to stay in Australia.

What if we cannot measure the current process at all?

Say so in the brief and make the measurement the first piece of work, with its own small budget and a decision point at the end of it. That is an honest brief and good vendors respond well to it. What does not work is inventing a baseline, because you will be held to it and afterwards you will not be able to prove the project delivered anything. Plenty of Australian SMEs genuinely do not know how many quotes they send in a month or how long a job takes to reach an invoice. Finding out is often worth more than the automation that follows it.

Can Yes AI help write the brief even if you do not get the work?

Yes. We run brief workshops as a standalone piece and you own the document at the end, to send wherever you like. If we also intend to quote, we tell you that at the start so you can decide whether you want a different pair of eyes on the comparison. We are an Australian consultancy that scopes, builds, integrates and supports, so we obviously hope to be in the running, and we would still rather you ran a proper process with three real responses. Book a call and we will start with your problem, not with our services.

Get the Brief Right Before You Go to Market

Book a call and bring whatever you have, even if that is one paragraph and a hunch. We will work through the problem, the real volumes and the constraints with you, and you will leave with the shape of a brief you can send to anyone. No obligation, no jargon, no pressure to use us for the build.