Start with one workflow that costs the most manual time. Prove value there before expanding.
Step 1: Describe the process as it actually runs today
Structure your AI system brief so developers can estimate accurately.
Write down the real process, including the messy parts, the exceptions, and the informal fixes your team uses to keep it running. A brief that describes the idealized version of the process, the one from the operations manual rather than reality, sets a development team up to build something that does not actually fit how your business works.
Involve the person who actually performs this process every day when writing this section. Their description will almost always include details, workarounds, shortcuts, judgment calls, that never made it into any official documentation, and are exactly the details a development team needs to build something that survives contact with your actual operation.
Include systems that only come into play occasionally, not just the ones used every day.
Step 2: Define what success looks like in numbers
Vague goals like faster or more efficient give a development team nothing to build toward or measure against. Put a number on it: response time under two minutes, error rate under two percent, processing time cut by half. Specific targets shape better technical decisions throughout the project.
These numbers also give you a fair way to judge the finished system later. Without them, any disagreement about whether the project succeeded becomes a matter of opinion instead of a matter of fact, and a matter of opinion is a poor foundation for a project that costs real money.
Step 3: List the systems it needs to talk to
Name every system the AI layer will need to read from or write to, along with how you currently access each one and whether it has an existing integration option. This single piece of information often determines the entire technical approach, and discovering it mid-project causes the most common source of delay.
Include systems that only come into play occasionally, not just the ones used every day. A reporting tool used once a month is just as important to list as the CRM your team touches constantly, because it still shapes what the finished system needs to support, and leaving it off the list is a common way otherwise well-planned projects run into an unplanned integration late in the build.
Working on something similar?
Let's talk →Step 4: Flag the edge cases you already know about
You will not think of every edge case in advance, and that is fine. But list the ones you already know cause problems today: the customer type that never fits the standard flow, the supplier whose invoices always look different, the exception your team handles manually every single week. These are exactly the cases that break systems built without knowing about them.
Ask your team directly: what is the one situation that always requires a workaround right now? Their answer is usually the single most valuable line in the entire brief. Ask a second and third person the same question, since different roles tend to notice different exceptions.
Step 5: State the outcome you need, not the solution you imagine
Describe the problem and the result you want in detail, and resist the urge to specify a particular technical approach unless you genuinely have a reason to require it. A brief that prescribes the solution too tightly can rule out a simpler or cheaper approach that a development team would otherwise have suggested.
If you do have a strong preference, a specific platform you already use, for example, state it as a constraint and explain why, rather than presenting it as the whole solution. A good development team will tell you plainly if that constraint creates a real problem, and it is far better to hear that before the project starts than partway through it.
Your pre-development checklist
Before you move forward, confirm:
- You have described the process as it actually runs, including its messy parts.
- Success is defined with specific numbers, not general goals.
- Every system the AI layer needs to connect to is listed with access details.
- Known edge cases and exceptions are documented explicitly.
- You have stated the outcome you need without prescribing the technical solution.
- Someone who runs the process daily has reviewed the brief before it goes out.
- You have asked at least two people on the team about known exceptions, not just one.
When you are ready to brief a development team, use our AI project specification template to lock scope before build.
