How to find and choose your first AI automation project

Find candidates in an ordinary working week

Ask the people doing the work to walk through recent tasks. Record what started each task, the tools they opened, what they copied or checked and where the work waited for someone else. Start with observation; an estimate or an unknown is more useful than an invented baseline.

What information did you copy from an email or document into another tool?
Which questions made you search the same documents again?
What did you have to check, correct or ask someone else to complete?
Where did work wait for an owner, an approval or missing information?
Which repeated task has a clear finished result that another person can check?

Separate AI opportunities from simpler improvements

Use the smallest approach that addresses the problem. Unclear ownership needs a process decision. Stable fields and exact rules may need ordinary automation. Varied language or document layouts may justify testing AI interpretation, with checks on its output.

Possible approaches to recurring work; suitability must be tested
Work you notice	First approach to examine	Why
Requests wait because nobody owns them	Assign an owner and clear handoff.	A model cannot decide organisational responsibility for you.
Copying fixed form fields into a sheet	Field mapping and validation rules.	The input already has a predictable structure.
Reading differently worded quote emails	Interpretation plus field validation and review.	The wording varies but the required output can be defined.
Searching a small current handbook	Navigation or ordinary search.	An answer generator may add unnecessary complexity.

Use this worksheet to compare candidate tasks

Copy these prompts into a document and complete one column for each task. Do not turn the answers into a universal readiness score: a serious access or error problem can outweigh frequent repetition.

Reusable task comparison worksheet
Prompt	What to record	If unknown
Volume and effort	Frequency, handling time and time spent correcting work.	Observe a representative period.
Input and output	Source, destination and a clearly correct result.	Map a real example end to end.
Access and examples	Permitted samples and feasible access to existing tools.	Ask the system and data owners.
Exceptions and review	What can go wrong, who checks it and whether it can be undone.	List difficult cases with the team.
Ownership and measurement	A responsible person and a baseline to compare against.	Agree these before proposing a build.

Worked example: choosing between three tasks

Hypothetical example, not a customer case: a small supplier considers quote intake, a weekly spreadsheet report and a policy assistant. The table shows assumed conditions and provisional choices, not measured savings or a ranking that applies to every company.

Fictional supplier: compare readiness before choosing a tool
Candidate	Assumed situation	Proposed next step
Quote intake	Repeated email entry; owner and approved samples available; drafts can be reviewed.	Validate extraction and review effort on the samples.
Weekly report	Stable spreadsheet exports and exact calculations.	Test ordinary automation before considering AI.
Policy assistant	Conflicting documents and no document owner.	Resolve ownership and versions before an AI pilot.

Estimate the work left after automation

Illustrative arithmetic only: suppose a task occurs 100 times a month and takes 6 minutes each time. That is 10 hours today. If a pilot later measures 3 minutes of review per request plus 2 hours of monthly maintenance, the remaining effort would be 7 hours, leaving 3 hours of capacity. These are invented assumptions, not our performance results.

Check exceptions, integration costs, software fees and support effort separately. Capacity released is not automatically cash saved. Use your own observed figures before deciding whether the first project is worthwhile.

Compare tasks before choosing a tool

If you want to introduce AI but do not know where to begin, list the tasks your team repeats. For each one, note how often it happens, time spent, tools involved, exceptions and the consequence of a wrong result. Compare these facts before choosing a model or automation platform.

Email intake, extracting fields from documents and finding approved internal answers are examples to investigate. A low-volume task with unpredictable decisions may be a poor first project even if a demonstration looks impressive.

Clear input and output: can another person tell when the work is complete?
Repeated effort: is there enough recurring work to measure a useful difference?
Available examples: can you test normal cases and exceptions with permission?
Manageable consequences: can a person catch and correct errors before important actions?

Question 1: Who owns the work?

Name the person responsible for the process. Agree on what starts the work, how it should end and who handles unusual cases. If two teams follow different rules today, automation will not solve that disagreement for them.

Question 2: Do you have useful examples?

Collect examples of normal, incomplete, duplicate, restricted and failed cases. Made-up examples are useful for designing a demo. The decision to use the workflow for real work must be based on examples approved by the customer.

Question 3: How will you know it works?

Choose the measurements before building. For a RAG tool, finding the right document and writing a supported answer are two different tests. For incoming requests, reading the fields correctly and sending the request to the right next step are also different tests.

Sources for this sectionMicrosoft Learn: Retrieval-Augmented Generation evaluators

Question 4: What may happen automatically?

List every action the workflow could take in another system. Decide which actions are blocked, previewed, approved by a person or allowed automatically. Start with actions that are low risk and easy to undo. This service is not intended for automatic legal, medical, hiring or credit decisions.

Question 5: What happens when something goes wrong?

Plan for missing data, weak search results, possible duplicates, access problems, timeouts and updates that only partly succeed. A workflow is not ready for a pilot if the team can only explain the happy path.

Question 6: Where does the data go?

Write down what enters the workflow, where it is stored, which service providers receive it, how long logs remain and who can open each source. NIST provides a useful list of AI risks, but the exact safeguards still depend on the customer's tools, contracts and security needs.

Sources for this sectionNIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

Question 7: Who watches it and how do you stop it?

Decide who watches for errors, retries failed steps and checks that other systems were updated correctly. Agree on when to pause the workflow and how the team will continue the work by hand. The owner should be able to explain both how to start it and how to stop it.

What affects the scope and cost of a pilot?

The number of input formats, integrations, permission boundaries and exception types all affect what needs to be built and tested. Document quality, available system access and the amount of human review also shape the proposal. A generic saving percentage cannot replace this assessment.

For a first discussion, prepare the task description, current tools, approximate volume and handling time, and the output you need. A validation sprint can then define the automation boundary, acceptance criteria and a fixed-scope pilot proposal. Pricing is confirmed after scope review; this guide does not promise a payback period.

When to move ahead

Move ahead when the task is clear, the examples are useful, the measurements are agreed, important actions are controlled, failures have an owner and the data plan is acceptable. If one answer is still unknown, solve that question before building more screens.

Apply this to one workflow

Still finding a starting point? We can help you identify opportunities. If you already have one task, use the free check or explore a scoped pilot. No files or customer data are needed for an initial inquiry.

Sources

Sources support the specific statements linked above. They do not establish that a tool or reference workflow will fit a customer's systems and data.