The AI Use Case Design Toolkit
How to find, assess and prioritise AI opportunities that solve real business problems
Aidelytica · Practical Resources
Each section starts collapsed — select a heading to expand it, or use “Expand all sections” in the Contents.
Notes stay on this device when saved; they are not sent to Aidelytica.
The most useful AI initiatives start with a specific business need. Yet teams often begin by asking what a new tool can do, then search for a place to use it. This can produce disconnected experiments, overlapping subscriptions and projects that are difficult to evaluate.
Use case design reverses that sequence. It begins with the work that needs to improve, examines the evidence, considers several possible solutions and defines how success will be measured. AI becomes one option to evaluate rather than the default answer.
An AI use case is a defined application of AI within a business process, with an identified user, purpose, input, expected output, operating boundary and measure of success. 'Use AI in customer service' is too broad. 'Draft responses to routine delivery enquiries using approved order data, with staff review before sending' is specific enough to evaluate.
Start by collecting problems from the people closest to the work: employees, customers, managers and support teams. Look for repeated manual tasks, delays, high volumes of similar requests, inconsistent decisions, information that is difficult to find, preventable errors and points where customers abandon a process.
Use more than one source of evidence. Interview staff, review process documentation, analyse service tickets and transaction data, examine customer feedback, and observe the workflow where possible. Avoid assuming that a task is worth automating simply because employees dislike it; understand its value, complexity and consequences first.
Opportunity discovery prompts
- Where does work wait for a person, approval or missing information?
- Which tasks require copying information between systems?
- Which customer questions recur, and what makes them difficult to answer?
- Where do errors, rework or inconsistent outcomes occur?
- Which decisions require searching multiple documents or summarising information?
- Which parts of the process consume time but add little value?
- What do customers struggle to find, understand or complete?
- What must remain human-led because it requires judgement, empathy or accountability?
Opportunity inventory worksheet
| Problem / task | Who is affected? | Frequency / volume | Current impact | Evidence source | Possible approaches |
|---|---|---|---|---|---|
Before designing an AI-enabled process, map how the work happens today. Record the trigger, steps, systems, decisions, handoffs, exceptions and final outcome. Include the work that is invisible in formal process maps: searching for information, checking results, correcting errors and following up with customers.
| Workflow stage | What happens today? | Delay / friction | Data or system used | Human judgement needed? |
|---|---|---|---|---|
| Trigger / intake | ||||
| Information gathering | ||||
| Decision or action | ||||
| Review / approval | ||||
| Completion / follow-up |
This step matters because AI can make an inefficient process faster without fixing the underlying problem. If the process contains duplicate approvals or unclear ownership, redesign it before automating it.
Compare at least three options: improve the process, use conventional automation, or introduce AI. AI may be useful when the input is variable or language-based, when information must be summarised across documents, or when a system needs to interpret a wide range of natural-language requests. It may be unnecessary where a simple rule, structured form or searchable knowledge base is sufficient.
| Approach | Consider it when | Example |
|---|---|---|
| Process improvement | The workflow itself creates waste or confusion. | Clarify who approves a refund before adding a tool. |
| Rules-based automation | The inputs and decision rules are stable. | Send a confirmation when a booking is recorded. |
| Search or knowledge management | People cannot reliably find approved information. | Create a maintained FAQ or searchable policy library. |
| AI assistance | A person benefits from drafting, summarisation, classification or interpretation. | Suggest a response to a delivery enquiry for staff review. |
| AI agent or action-taking system | The task requires multiple steps or actions across tools. | Assist with a booking using live availability, confirmation and escalation controls. |
The more autonomy a system has, the more carefully you should evaluate permissions, reversibility, failure modes and human oversight. Start with assistance or recommendations when the evidence does not yet support autonomous action.
A well-written use case is specific enough that a team can assess feasibility, compare vendors and design a test. Use the canvas below before requesting proposals or starting development.
AI use case canvas
| Field | Questions to answer | Your notes |
|---|---|---|
| Use case name | What short name describes the workflow? | |
| Problem statement | What is happening now, and why does it matter? | |
| Target users | Who uses the system or is affected by it? | |
| Trigger and inputs | What starts the process and what information is required? | |
| Proposed AI role | What will AI generate, classify, retrieve, recommend or do? | |
| Human role | Who reviews, approves, corrects or handles exceptions? | |
| Output / action | What result is produced, and where does it go? | |
| Data and systems | Which sources are needed, and who owns them? | |
| Boundaries | What is prohibited or outside scope? | |
| Expected value | Which customer, employee or business outcome should improve? | |
| Measures | What baseline and target will demonstrate success? | |
| Risks and controls | What could go wrong and how will it be detected or limited? | |
| Owner | Who is accountable for the result and ongoing operation? |
A winery receives website and phone enquiries outside business hours. Staff currently respond the next day. The opportunity is not simply ‘install a chatbot’; it is to help customers obtain reliable answers and complete supported bookings when staff are unavailable.
| Canvas field | Example response |
|---|---|
| Problem | Customers cannot always get an immediate answer about available booking options. |
| Users | Prospective visitors and the bookings team. |
| AI role | Answer approved FAQs and guide customers through a supported booking flow. |
| Required information | Current booking availability, approved prices, policies and venue details. |
| Human role | Handle unusual requests, complaints, group bookings outside standard rules and uncertain cases. |
| Boundary | Never invent availability, promise exceptions or confirm an action that the booking system has not recorded. |
| Measures | Completed bookings, failed attempts, correct answers, escalation quality, customer feedback and staff follow-up time. |
| Pilot | Limited hours or traffic, supervised review and a clear fallback to the existing booking process. |
Before proceeding, verify that the booking platform exposes reliable availability and booking actions. If it does not, the first project may need to improve the booking process or connect the underlying system before an AI assistant can be dependable.
Assess both potential value and the effort required to realise it. Value may include time saved, reduced rework, more completed transactions, better customer access, improved consistency or faster access to information. Feasibility depends on data quality, integration, process stability, staff capacity, vendor fit and the ability to test the outcome.
Use conservative estimates and state assumptions. For time savings, distinguish time removed from the process from time shifted to checking AI outputs. For revenue opportunities, avoid attributing all additional sales to AI unless you can establish a credible comparison.
Value estimation worksheet
| Input | Estimate / source |
|---|---|
| Tasks or interactions per month | |
| Average time per task today | |
| Expected time saved per task | |
| Proportion requiring human correction | |
| Estimated value of staff time | |
| Potential change in conversion or completion | |
| One-off implementation cost | |
| Monthly software and usage cost | |
| Ongoing review and maintenance cost | |
| Key assumptions and uncertainties |
A simple estimate of gross time capacity released is: monthly task volume × minutes saved per task ÷ 60. This is not automatically a cash saving. To estimate financial impact, consider whether the released time can be redeployed productively, whether staffing or overtime changes, and what additional quality or service costs arise.
Some use cases should not proceed merely because their projected return is attractive. Identify potential impacts on customers, employees and other people, including privacy, security, unfair outcomes, inaccurate information, accessibility, reputational damage and loss of human recourse.
- What personal, confidential or commercially sensitive information is involved?
- Could an incorrect output affect a person's rights, access to services, money or safety?
- Could the system disadvantage a group or reproduce bias in existing data?
- Can a person understand, review and override the output?
- Can the system explain uncertainty and hand off to a suitable person?
- Can errors be detected, corrected and reversed before harm occurs?
- Are the data, supplier terms and intended use appropriate and authorised?
Use risk gates as well as a score. For example, a use case involving sensitive data or consequential decisions may require specialist privacy, legal, security or domain review before it can be considered for a pilot. If a critical risk cannot be controlled to an acceptable level, reject or redesign the use case.
Once the opportunities are defined, compare them using consistent criteria. The following scorecard is a starting point. Adjust the weights to fit your business, but agree on them before scoring so that criteria are not changed to favour a preferred project.
| Criterion | Weight | Score 1–5 | Scoring guidance |
|---|---|---|---|
| Business / customer value | 25% | 1 = marginal; 5 = substantial, evidenced impact | |
| Feasibility | 20% | 1 = major unresolved barriers; 5 = feasible with current capability | |
| Data readiness | 15% | 1 = unavailable or unsuitable; 5 = reliable, permitted data | |
| Implementation effort | 15% | 1 = high effort; 5 = relatively simple | |
| Measurability | 10% | 1 = difficult to evaluate; 5 = clear baseline and outcome measures | |
| Adoption readiness | 5% | 1 = limited ownership or acceptance; 5 = strong support | |
| Strategic fit | 10% | 1 = weak alignment; 5 = directly supports priorities |
Calculate the weighted score by multiplying each rating by its weight and dividing by 5, then adding the results. The result is a prioritisation aid, not a decision in isolation. Apply risk and compliance gates separately, and document why an opportunity was selected, deferred or rejected.
How to interpret the results
- High value, high feasibility: a candidate for a controlled pilot, subject to risk review.
- High value, low feasibility: investigate data, integration, process or capability gaps before committing.
- Low value, high feasibility: consider only if the cost is low and it supports a useful learning objective.
- Low value, low feasibility: deprioritise unless new evidence changes the case.
For the highest-priority use case, write a short pilot brief. Specify the users, workflow boundary, duration, data, owner, expected outcome, evaluation method and conditions for stopping. Test routine cases and difficult cases. Agree what counts as a successful result before looking at the outputs.
| Pilot brief field | Decision to document | Your notes |
|---|---|---|
| Hypothesis | What do we believe will improve, and why? | |
| Scope | Which users, tasks and channels are included or excluded? | |
| Baseline | What is the current performance? | |
| Success criteria | What thresholds must be met for value, quality and risk? | |
| Test cases | Which normal, edge and failure cases will be evaluated? | |
| Oversight | Who reviews outputs and handles exceptions? | |
| Stop conditions | What failure or incident requires pause or rollback? | |
| Review date | When will the team decide to scale, change or stop? |
The output of use case design should be a decision, not just a list of ideas. Each candidate should have a clear status: proceed to a pilot, investigate a prerequisite, revisit later, or reject. Record the reason and assign an owner to any next action.
For approved pilots, use the AI Implementation Roadmap to plan testing, training, launch and ongoing monitoring. Use the AI Tech Stack guide to compare solutions against the requirements created in the use case canvas.
This toolkit is intended as a practical starting point, not a substitute for specialist advice where legal, privacy, safety or other high-impact risks are involved.
The Aidelytica approach: identify the problem, design the use case, choose the technology and implement with evidence, clear ownership and appropriate human oversight.