How to scope a custom AI system before talking to anyone

The cheapest way to save money on a build is to scope it well before anyone quotes it. A clear scope is not a spec document; it is a short, honest answer to what the system does, for whom, and how you will know it worked. Do this work yourself first and you arrive at any conversation with the hard thinking done, which shortens the build and protects your budget.

Step by step

1. Name the one job the system doesWrite a single sentence that says what the system does and for whom. Not a list, one job: sort incoming enquiries, draft the first quote, flag overdue documents. If you need the word and, you probably have two systems, and bundling them is how scope bloats. A build with one clear job is easy to price, easy to test, and hard to argue about later. Start there.
2. Map the inputs it receivesList exactly what goes in: an email, a form, a spreadsheet row, a scanned docket, a customer message. For each input, note where it comes from and what shape it is in today. Systems fail on messy inputs far more than on clever logic, so being honest here about the state of your data saves real money later. If an input does not exist yet in a usable form, that is scope you have just found.
3. Map the outputs it producesDescribe exactly what comes out and who receives it: a drafted reply in someone's inbox, a record written to your system, an alert, a ranked list. Be specific about the format and the destination. An output nobody uses is wasted build, so tie every output to a person and a decision they make with it. If you cannot name the person, the output does not belong in scope.
4. Set the numbers that prove it workedDecide, before anyone builds, how you will know the system did its job. Hours saved a week, response time cut, errors caught, quotes out the same day. Pick one or two numbers you can actually measure and write down where they sit today. Without a baseline you cannot prove value, and a build with no measure of success tends to grow forever because nobody can say when it is done.
5. Draw the boundary of what it will not doWrite down what is explicitly out of scope. This one job, not the three next to it. This input, not every variant. Naming the boundary is how you stop a tidy build turning into a platform. Every capability you leave out is money and time you keep. You can always add the next job once the first one is paying for itself, and that sequencing keeps a project moving.
6. Write it as one page a stranger could readPut the job, inputs, outputs, success numbers and boundary on a single page. If a person who does not know your business can read it and repeat back what the system does, your scope is tight enough to price. If they cannot, keep cutting until they can. That one page is the most valuable thing you can bring to a build conversation, and it costs you nothing to write.