How to Define a Business Problem Before Buying AI Software
Before buying AI software, describe what is going wrong in your business without naming a tool. Identify the affected workflow, the observable problem, who experiences it and what a satisfactory result would look like. Then separate what you know from what you still need to investigate.
The useful output is a short problem brief, not a software shortlist. A colleague or prospective supplier should be able to read it and understand the issue without being steered towards AI as the answer.
This guide explains how to write that brief, using an illustrative order-processing example. It focuses on defining one problem clearly, rather than choosing which tasks to automate or comparing software types.
Practical guidance: describe the problem, not the purchase
“We need an AI assistant” is a proposed solution. “Staff repeatedly chase missing order details before work can begin” describes an observable difficulty. The second statement leaves room to investigate whether the answer is a clearer form, a process change, business automation or something else.
Start with this sentence:
When [a specific event happens], [a person or team] encounters [an observable difficulty], which affects [a business activity or outcome].
For example: “When customer orders arrive without required specifications, the administration team must request clarification before handing them to operations, leaving those orders waiting for review.”
This does not claim to explain the cause. It simply identifies a situation that can be checked. Avoid words such as “inefficient” or “outdated” unless you explain what they mean in observable terms.
This problem-first approach also aligns with Australian Government business guidance on identifying business problems and goals before researching suitable AI solutions. The important distinction is between evidence of a problem and enthusiasm for a particular technology.
Draw a boundary around one workflow
A problem described as “too much administration” is too broad to investigate usefully. Choose a recognisable starting event and an ending condition. For the order example, the boundary might run from receiving an order to accepting it as ready for operational review.
Write down what happens inside that boundary:
- Who receives the information?
- What must they check before passing it on?
- Where does the work wait, return or change hands?
- What tells everyone that this stage is complete?
Record the actual process, including workarounds, rather than only the documented procedure. Ask someone who handles ordinary cases and someone who deals with exceptions to describe their experience.
Also state what is outside scope. In this example, stock purchasing, fulfilment and invoicing might remain excluded. They may matter later, but including them now would turn a bounded investigation into a much larger project.
Separate symptoms, possible causes and missing evidence
A queue of unfinished work is a symptom. Its cause might be incomplete information, unclear responsibility, competing priorities or a difficult decision. Treat these as hypotheses until you have checked them.
Use three headings in your notes:
- Observed: what a record or direct observation shows.
- Possible explanation: what someone thinks is causing it.
- Still unknown: what you need to examine before deciding.
For instance, an employee may report that customers frequently omit specifications. Check a sample of orders to see which details are missing, whether customers were asked for them and whether the same issue occurs across different order types.
Keep the sample boundaries visible. Record the period examined, how cases were selected and any unusual circumstances. If your evidence covers only one team or a busy period, do not describe it as representative of the whole business.
At this stage of business process automation planning, uncertainty is useful information. “We do not yet know why these cases wait” is more actionable than an unsupported conclusion that a new system is needed.
Define the impact without inventing a business case
Explain why the problem deserves attention. Distinguish active work from elapsed waiting: an order can sit unanswered for a long period while requiring only a short clarification task. Those are different problems and may need different responses.
Where records allow, examine:
- The number of cases entering the defined workflow.
- The share requiring clarification or rework.
- The handling effort involved in those cases.
- The point at which waiting starts and ends.
- The consequences for the next person or activity.
Label estimates as estimates and explain their basis. Do not turn a staff member’s rough impression into a precise annual saving. If reliable measurements are unavailable, specify what you will collect and who will collect it.
Not every consequence needs a dollar value immediately. Repeated handbacks, uncertainty about case status and avoidable interruptions can be described directly. Financial projections belong in a later assessment once the baseline and proposed intervention are clear.
Write acceptance criteria before discussing features
An acceptance criterion describes how you would judge a proposed change. It is not a feature request such as “include a chatbot” or “use an AI agent”.
For the order-processing example, suitable criteria to refine with the team might include:
- Orders cannot be marked ready while required specifications remain unresolved.
- Staff can identify which information is missing and who must supply it.
- Unusual requests remain available for an authorised person to review.
- A change does not increase incorrect handovers to operations.
Set measurable targets only after examining the baseline and agreeing what is acceptable. Include a balancing measure so that improving one activity does not conceal deterioration elsewhere. Faster processing, for example, should not be assessed without also checking accuracy.
Keep practical automation separate from the desired outcome. A clearer customer form and an AI-based proposal should be judged against the same problem definition, even though their methods differ.
Turn the findings into a one-page problem brief
Bring the investigation together in a document that someone outside the workflow can understand. Use the following fields as a working template.
- Problem: describe the observable difficulty in one or two sentences.
- Boundary: name the starting event, ending condition and exclusions.
- People affected: identify the team doing the work and the people receiving its output.
- Evidence: summarise what you examined and its limitations.
- Impact: distinguish handling effort, waiting, rework and downstream consequences.
- Desired result: define acceptance criteria and balancing measures.
- Constraints: record information-access limits, approval boundaries and decisions requiring human judgement.
- Open questions: list unresolved causes and the next evidence needed.
An illustrative summary might read: “Orders missing required specifications cannot proceed to operational review. Administration staff request clarification, but we have not established how often this happens or which omissions dominate. We will examine a defined sample before selecting an intervention. Any proposal must preserve human review of unusual requests.”
Notice what this brief does not say: it does not assume AI is necessary, promise savings or specify a product. It gives the investigation a clear direction while keeping the solution open.
Check whether the brief is ready for a supplier conversation
Ask a colleague unfamiliar with the issue to explain the brief back to you. If they cannot identify the affected workflow, the evidence and the desired change, revise it before requesting proposals.
Then ask prospective suppliers to distinguish what their proposal addresses from what it leaves unresolved. A useful discussion should expose assumptions, dependencies and the evidence needed for a test. A demonstration alone does not establish that your business problem has been solved.
If the evidence points to unclear instructions or missing ownership, address those findings rather than preserving an AI purchase as the goal. A well-defined problem may lead to software, a simpler process change or a decision to investigate further. Each is a legitimate outcome of the exercise.
Preparation checklist
- The problem describes observable work, not a preferred tool.
- The workflow has a clear beginning, end and scope boundary.
- Evidence, estimates, possible causes and unknowns are distinguished.
- Acceptance criteria describe the desired change and what must not deteriorate.
- An accountable owner has agreed on the next investigation or decision.
Frequently asked questions
How specific should a business problem statement be?
Specific enough that another person can locate the workflow, recognise the difficulty and understand its consequence. Name the triggering event and affected team. Keep detailed evidence in the brief rather than trying to fit the entire investigation into one sentence.
What if we do not have reliable process data?
Write a provisional statement and label the gaps. Record staff observations separately from measured facts, then choose a bounded sample of real cases to examine. Do not substitute invented figures for missing evidence.
Should AI appear in the problem statement?
Usually, describe the operational problem without prescribing AI. Record AI as a possible approach to assess later. An exception is when the problem concerns an existing AI system; in that case, describe its observed behaviour without assuming the cause.
Who should agree on the problem brief?
Include the person accountable for the workflow, someone who performs the work and a representative of the team receiving its output. Involve relevant information or approval owners when the proposed investigation touches their responsibilities.
A problem brief as a starting point for an audit
Transive AI offers a guided business audit. A written problem brief is a useful starting point for an audit discussion: it sets out the workflow you want to examine, the evidence already available and the questions that remain open.
Keep the brief solution-neutral so that the business need, rather than a preferred technology, remains the basis for discussion.
Take the next step
Before your next conversation about AI software, prepare a short problem brief. Bring the workflow boundary, a few representative examples and your unanswered questions so the discussion starts with the work that needs attention.
