Skip to content
I.STEM Lab

Guide · AI Strategy

Your first AI pilot: pick one task and measure it for 30 days

A practical plan for small teams: choose one repeated task, set a baseline, try a tool for a month and decide with evidence.

Beginner6 min read

Key takeaways

  • Start with one painful, repeated task, not a grand AI strategy.
  • Record the time or cost per task before you begin, or you will have nothing to compare.
  • Set a small, fixed budget and a calendar date for the decision.
  • Keep a person responsible for checking what the AI produces.

If you run a small team or a small organisation, the flood of advice about AI can be paralysing. Conferences talk about transformation. Vendors promise miracles. Meanwhile you have a full inbox and no time. The honest, effective answer is much smaller: pick one task, try one tool for thirty days, measure the result and decide.

This guide shows you how to run that first pilot. It needs no technical staff and little money, and it produces something precious: evidence from your own work, rather than someone else’s promises.

Step 1: find the right task

Look for a task that you or your team do often, that follows a fairly clear pattern and that takes more time than it deserves. List five or six candidates, and score each on three questions.

  • Frequency: how many times a week does it happen?
  • Pattern: is it mostly rule-based, or does it need real human judgement?
  • Time: how many hours does it take across the team each week?

Good first tasks tend to be writing and summarising jobs: first drafts of emails and documents, summaries of meetings and long reports, answering the same customer questions again and again, or pulling figures out of invoices and forms. Poor first tasks are those where a mistake is costly and hard to spot, such as legal advice or final financial decisions.

Step 2: record the baseline

Before you try anything, measure how the task is done today. Time several real examples, and note the quality and the number of corrections. Without a baseline, you will only have a feeling, and feelings about new technology are unreliable in both directions.

  • Minutes per task, averaged over at least ten examples.
  • Number of tasks per week.
  • Common errors or rework.
  • Who does it, and how they feel about it.

Step 3: choose the tool and set the guardrails

Choose after you have chosen the task, not before. For a first pilot, a general-purpose assistant or a feature in a tool you already use is usually enough. Before anyone starts, agree three rules.

  1. 01What information may and may not be entered. Do not paste confidential, personal or customer data into a service unless you have checked its terms.
  2. 02A human reviews everything before it leaves the building.
  3. 03A fixed monthly budget, a small one, with a named person who can stop the pilot at any time.

Step 4: run it for thirty days

Use the tool on the real task, every time it comes up, for the full month. Ask the same people to log the time taken and to mark each result as used as it was, edited or thrown away. A short note on what worked or failed takes seconds, and is worth a great deal.

Hold a ten-minute check-in each week. Teams that review early adjust early, and avoid the common story of trying a tool for a week, getting confused and giving up.

Step 5: compare and decide

At the end of the month, set the results beside your baseline.

  • Time saved per task, and across the month.
  • Quality: how often the output was used with little or no change.
  • Errors caught by the human review, which show the real risk.
  • Cost: the subscription plus the time spent on review.
  • Experience: would the team keep using it if it were optional?

Then decide with a clear rule. Keep it and extend it, change the task or the tool and run another month, or stop. All three are good outcomes, because all three are based on what you saw.

What a good result looks like

You do not need a dramatic number. If a weekly task that took four hours now takes two, and the team is happier, that is a real gain of about a hundred hours a year, from a small experiment. The pilot also teaches your team how to work with AI, and that skill grows with every use.

Where first pilots go wrong

  • Choosing a popular tool before defining the problem.
  • Skipping the baseline, so nobody can say whether anything improved.
  • Letting AI output go out unchecked.
  • Choosing a task too important or too complex for a first try.
  • Running it for a few days and judging from a bad first impression.
  • Putting private data into a tool without checking where it goes.

After the pilot

A worked example: the weekly report

A small organisation spends about four hours each week turning field notes into a summary report for its board.

  1. 01Baseline: the team times the task over six weeks. It averages 3 hours 50 minutes, and the writer says the first draft is the worst part.
  2. 02Rules: no names or personal details go into the tool, the writer reviews every line, and the budget is a small monthly subscription.
  3. 03Pilot: for four weeks, the writer pastes anonymised notes into an AI assistant, asks for a structured first draft and then edits it. She logs the time and notes what she changed.
  4. 04Result: the average falls to 1 hour 45 minutes. About two thirds of the draft is kept with light edits, and twice the tool invented a figure that review caught.
  5. 05Decision: continue, with a rule to check every number against the source, and extend the approach to meeting minutes next.

The saving, about two hours a week, is modest, but the team learned how to brief the tool, which mistakes to look for and how to measure benefit. That learning is what makes the second pilot easier.

Frequently asked questions

How do I choose between tools?
Pick a task first, then try one or two tools on real examples. Prefer the one your team finds easiest, and check its data policy.
What if the team is worried about their jobs?
Be open about the goal, which is to remove tedious work. Involve them in choosing and testing, and share the results.
Is thirty days enough?
It is enough to see a clear pattern for a frequent task. For rare tasks, extend the pilot or choose a more frequent one.
What should we never put into a public AI tool?
Personal data, passwords, confidential contracts and anything you would not email to a stranger, unless you have checked the tool’s terms and have approval.

Write half a page: the task, the baseline, the result, the lessons and the decision. Share it with your team. Then pick the next task, and repeat. Over a year, a series of small, measured steps builds both real savings and real confidence, which is a far better route than one large programme that never quite lands.

Share

Join the conversation

Reactions & comments

Comments are opening soon.

In the meantime, tell us what you think by email at info.istem.lab@gmail.com.

Start a project

Need this built for your organization?

If you would rather have a working system than a tutorial, tell us your goal and we will scope it with you.