In brief
- Start with a concrete workflow or a verifiable outcome.
- Assess value and feasibility separately.
- A frequent, well-defined task is usually a better starting point than a broad vision.
- Define success criteria and stop-or-continue decisions before development begins.
Start with the problem, not the technology
Many initiatives begin by asking where a chatbot or agent could be used. A better question is which current workflow loses time, creates avoidable errors or makes knowledge difficult to access. Only a concrete description of the current situation can show whether AI is an appropriate tool.
- Which workflow or outcome should improve?
- Who handles it today and how frequently does it occur?
- Where do delays, searches, handoffs or quality issues arise?
- Which improvement would employees or customers genuinely notice?
Does this problem need AI at all?
Not every valuable initiative is an AI use case. The best solution is the simplest approach that completes the task reliably, transparently and economically. Before testing a model, compare it with rules, search, system interfaces and improvements to the underlying process or data.
A concrete contrast makes the choice clearer: if a purchase approval depends only on structured amount thresholds, cost centres and supplier status, a rules-based workflow is sufficient. If differently formatted invoices must first be read and their line items proposed for review, AI can handle the variable document interpretation while binding approval logic remains conventional software.
- Clear rules and structured inputs: use conventional workflow automation.
- Exact current values or binding transactions: query the system of record through an API.
- Simple discovery of approved content: improve conventional search and navigation first.
- Unclear workflows, inconsistent data or missing ownership: repair the process and data foundation first.
- Variable language or content with a reviewable outcome: AI may help classify, summarise or prepare a draft.
Make the expected value measurable
Terms such as efficiency, quality or better decisions are not sufficient goals. A useful use case connects the expected benefit to an observable metric and a known baseline. Measurement can remain simple, but it must be defined before the test begins.
- Processing or search time per case
- Percentage of complete or correctly handled cases
- Number of manual handoffs or follow-up questions
- Response time and service availability
- Cost per case or employee hours released
Check feasibility against data and workflow
An attractive idea is not automatically feasible. Required inputs must be accessible, sufficiently complete and usable for the intended purpose. The output must also fit the existing workflow, and someone must be able to take professional ownership of its quality.
- Are representative inputs and real test cases available?
- Is the required knowledge stored in documents, databases or business systems?
- Can subject-matter experts judge a good result consistently?
- Which integrations and permissions are required?
- Who owns content, testing and ongoing improvement?
Assess the consequences of errors and required controls
The more an output affects people, money, rights or binding decisions, the stronger the required controls. Good initial use cases create meaningful value without allowing a single error to cause immediate or irreversible harm.
- Can a person review the result before it is used?
- Is an error visible and reversible?
- May the system only recommend, or may it also act?
- Are sensitive or confidential data involved?
- Which cases must be refused or escalated to a specialist?
Four dimensions in the decision grid
A grid makes different ideas comparable, but it does not replace a domain decision. Assess every dimension using observable evidence rather than one overall impression. A risk that cannot be controlled may remain a disqualifier even when expected value is high.
| Dimension | Strong signal | Warning signal | Evidence before starting |
|---|---|---|---|
| Value | A frequent or important task with measurable improvement in time, quality or service. | A general innovation objective without a baseline or affected user group. | Current duration, error rate or cost together with a target and measurement period. |
| Feasibility | Representative data, accessible systems and an accountable domain owner are available. | Essential information is missing, contradictory or not permitted for use. | A small sample of real cases, data approval and confirmed integration assumptions. |
| Verifiability | A good result and relevant errors can be identified consistently before use. | Assessment remains subjective or becomes visible only after an irreversible effect. | Test cases with expected claims, tolerances, refusal cases and named reviewers. |
| Risk and control | Errors are bounded, reversible and reviewed before consequential action. | The system affects rights, money or people without effective approval and fallback. | Data classification, permitted actions, approvals, escalation and stop criteria. |
Make an evidence-based starting decision
Not every promising use case should move directly into production. The assessment should first identify which uncertainty needs to be resolved next. A small test can prove technical feasibility, while a pilot also examines value in real work.
- Step 1
Define the problem
Describe the users, task and desired outcome precisely.
- Step 2
Measure the baseline
Record current quality, duration and effort using a small set of metrics.
- Step 3
Assess value, feasibility and risk
Document assumptions and unresolved questions.
- Step 4
Choose the smallest useful test
Build only what is needed to answer the most important uncertainty.
- Step 5
Set a decision point
Define in advance when to stop, adjust or invest further.
Example: Triage incoming service requests
A technical support team receives requests by email. Employees currently read every message, look up the customer number and select the responsible specialist group manually. An initial pilot covers only frequent categories that can be distinguished clearly. The team measures correct routing, time saved and required corrections. The system initially proposes a destination, while employees retain the final decision. This tests value and error consequences with real cases without automating the entire support process.
What to remember
Prioritise the use case where a relevant problem, suitable data, verifiable outcomes and manageable error consequences come together, not the idea that sounds most impressive.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed