Stop selling automation.
Sell a clear answer to a business problem.
AI can already build more than most people realise.
It can sort files, read documents, move information between tools, draft messages, and run repeatable workflows.
The hard part is not always the build.
The hard part is telling it what the business actually needs.
"Build an AI system for my sales team" is not a requirement.
It is a wish.
A requirement sounds more like this:
When a new enquiry arrives, collect the company name, check whether it fits our service area, draft a reply, and send it to a person for approval within five minutes.
That can be built.
The first sentence cannot.
the profit signal
Signal strength: 8/10
Buyer pain: clear
Build difficulty: low
Monetization: requirements sprint first, implementation second
Risk: a polished brief can still describe the wrong problem
The current AI conversation is full of tool tutorials.
But the useful business skill is moving up a level:
- Find the costly problem
- Describe the current process
- Define the output
- Name the exceptions
- Set the approval point
- Decide what success means
That is the work between a business and an AI system.
Call the document a Business Requirement Brief.
the idea in one sentence
Turn a messy business request into a clear brief that a builder or AI agent can execute without guessing.
what goes in the brief
1. The business outcome
What should improve?
Save two hours a week?
Reply to every enquiry within five minutes?
Reduce invoice errors?
Choose one outcome.
2. The current process
Write what happens today.
Use a real example, not the ideal version.
Where does the work start?
Who touches it?
Where does it wait?
What gets copied, checked, or fixed?
3. The inputs and output
List what the system receives and what it must produce.
Inputs: form, email, PDF, spreadsheet, transcript
Output: task, reply draft, report, folder, database record
If you cannot name the input and output, the workflow is still foggy.
4. The rules and exceptions
Tell the agent what changes the path.
For example:
If the enquiry is inside our service area, continue.
If it is outside the area, draft a polite decline.
If the budget is unclear, ask one question.
If the message contains a complaint, send it to a person.
Rules stop the system from treating every case as the same case.
5. The human checkpoint
Say where a person must review the work.
Anything involving a customer promise, payment, sensitive data, or a business record should have a clear approval point until the workflow is proven.
6. The definition of done
Finish with a testable sentence:
Done means every new enquiry is logged, classified, drafted, and placed in an approval queue with the right owner.
That gives the agent somewhere to stop.
use this prompt
You are a business systems analyst.
Turn the notes below into a Business Requirement Brief with these sections:
1. Business outcome
2. Current process
3. Inputs and source systems
4. Desired workflow steps
5. Rules and decision points
6. Exceptions and failure cases
7. Human approval points
8. Output format
9. Access or integration needs
10. Success measures
Rules:
- Do not choose tools until the workflow is clear.
- Do not invent missing requirements. Mark them as QUESTIONS.
- Separate facts from assumptions.
- Keep the first version small enough to test manually in one day.
- End with a short definition of done.
Notes:
[PASTE BUSINESS NOTES HERE]
how this turns into money
You can sell the brief as the first step of an implementation project.
The deliverable is simple:
- One business outcome
- One current process map
- One list of inputs and outputs
- One set of rules and exceptions
- One approval plan
- One definition of done
Then offer to build the smallest version that passes the test.
This is easier to scope than "an AI transformation."
It also gives the buyer something useful even if they decide not to build yet.
your 60-minute test
Pick one repeated task.
Ask the operator to show you the last real example.
Write down the current process in plain language.
Run the prompt.
Read the brief with the operator and mark every wrong assumption.
Then ask an AI agent for an implementation plan.
Do not build until the operator says:
Yes. That is what we actually need.


Leave a Reply