The first useful question about business AI is often a simple one: which task does your team repeat, and what would a better version of that task look like?
You might have several candidates. People search through folders for the same answer. Someone copies information from an email into another system. A team rewrites similar briefs every week. Reports arrive late because the underlying information lives in too many places.
Each could be a useful starting point. Choosing one means looking at the work, its inputs and the consequences of a mistake before choosing a model or platform.
This guide gives you a practical way to prepare that first pilot. If the vocabulary is new, the earlier articles in this series cover what AI is, how language models differ from AI applications, how to give AI a useful brief and why AI can be wrong. Each stands on its own, so read this one first if you prefer.
Step 1: Task · Overview
Pick one recurring task with an owner.
Read all steps as a list
- Task. Pick one recurring task with an owner. Write down who starts it, which information they use, what they produce and who checks it.
- Inputs. Check the information is usable and authorised. List documents, records and accounts, who controls access, and which providers may process them, including extraction, storage, logs and backups.
- Output. Agree what a useful result looks like. A reviewer should be able to judge the output without guessing what success means.
- Review. Decide what needs a person. Separate actions the system may take from actions a person must approve, based on the cost of a wrong action and whether it can be reversed.
- Baseline. Record how the work is done today. Measure time to an acceptable reviewed output, corrections needed, failures and cost, so the pilot is compared on the same terms.
- Pilot brief. Write the one-page brief. Task, owner, inputs and access, expected output, review boundary, evaluation and operations.
Start with a recurring task#
Write down three tasks your team repeats. Describe what happens, who does it and what the result should be.
“Use AI in our agency” is too broad to evaluate. “Turn an approved client brief into a draft content plan for a strategist to review” gives you a specific beginning and end.
For each candidate, ask:
- What starts the task?
- Who owns it?
- Which information does the person use?
- What do they produce?
- Who checks the result?
- What happens if something goes wrong?
Choose a task that happens often enough to observe and has a person who can judge the result. A process nobody owns is hard to improve or evaluate.
Check the inputs before designing the automation#
A workflow needs usable, authorised information. List the documents, records and accounts involved, then identify who controls access to each one.
For a content plan, the inputs might be a client brief, approved product facts, brand guidelines and a list of previous campaigns. Decide which source takes priority when two documents disagree. If key facts are missing, the workflow should ask for them or flag the gap.
This step also helps define the data boundary. Who may read the information? Which providers may process it? Does the task require a client-owned environment or an approved cloud service? Include extraction, storage, logs and backups in that discussion, as well as the model itself.
Use synthetic or approved sample data when exploring an idea. A public contact form or an unreviewed demonstration is not the place to upload confidential business documents.
Define one useful output#
Agree on a concrete result before building. A reviewer should be able to decide whether the output is useful without guessing what success means.
For a draft content plan, that could mean:
- The required sections are present.
- Client facts are traceable to the supplied material.
- Suggestions are distinguishable from confirmed facts.
- Missing information is listed as a question.
- The plan is editable by the responsible strategist.
A pilot does not have to complete an entire business process. Producing a useful reviewed draft may be a sensible first scope. Publishing content, sending messages and changing customer records can be separate decisions.
Decide what needs a person#
Identify the actions the system may take automatically and the actions a person must approve.
A draft stored for internal review has a different consequence from an email sent to a customer or a post published on a client's account. Consider the cost of an incorrect action, whether it can be reversed and who needs to authorise it.
Make the review useful. Show the proposed output, relevant evidence, unresolved questions and the action approval will permit. If an important fact changes after review, decide whether approval must happen again.
The boundary should be explicit. A button labelled “Approve” is meaningful only when the team knows what happens next.
Establish the current baseline#
Observe the existing workflow before deciding what the new one has improved. Record representative examples and the time needed to produce an acceptable result, including review and corrections.
For the pilot, track the same outcome. Useful measures can include:
- Time to an acceptable reviewed output.
- Amount of correction required.
- Missing or incorrect information.
- Task failures and manual recovery.
- Operating cost for a completed task.
Set acceptance conditions with the person responsible for the work. Avoid a vague goal such as “save a lot of time”. Also avoid comparing the system's first draft with the human process's finished output; account for the work needed to make each result usable.
A fictional agency example#
Imagine an agency preparing a weekly content plan for one client. This is an illustrative scenario, not a customer case study or a measured result.
The pilot starts when a strategist submits an approved brief. It uses the client's current brand guide and verified business facts. It produces a draft plan, a list of assumptions and questions that need an answer.
The strategist reviews and edits the output. The pilot does not connect to social accounts or publish anything. Its first purpose is to test whether the team can reach an acceptable plan with less avoidable effort.
The evaluation includes different briefs: one complete, one missing an important fact and one containing conflicting instructions. The reviewer checks whether the system handles each situation appropriately rather than simply producing confident text.
If the pilot proves useful, the next step could be an approved asset-production workflow. Publishing and reporting would need their own scope, access and acceptance conditions.
Write a one-page pilot brief#
Before speaking to an implementation partner, prepare this outline:
Task:
The recurring work we want to improve.
Owner:
The person who can decide whether the result is useful.
Inputs and access:
The sources, systems, permissions and processing constraints.
Expected output:
The result and what makes it acceptable.
Review and action boundary:
What may happen automatically and what needs approval.
Evaluation:
Representative examples, baseline and acceptance conditions.
Operations:
Budget, support owner and what happens when the task fails.
You do not need every technical answer at this stage. Identifying the unknowns is part of preparing a useful assessment.
Expand after the pilot proves its value#
Review the result with the people doing the work. Was the output useful? How much correction did it need? Were the data and action boundaries respected? What did the complete task cost to operate and support?
Use those answers to decide whether to improve the pilot, stop it or extend the workflow. Each new action should have a clear owner and an acceptance condition.
If you are preparing a first project, tell us which workflow your team repeats. We can discuss the requirements and an appropriate scope for a pilot.