Before you start
You need three things: one person who owns the project, a couple of hours of their time each week, and permission to change how one process works. You don't need a budget for new software yet. Most of the first month is about choosing well and measuring.
One process, not a strategy. A working tool that saves five hours a week teaches you more than a 40-page AI strategy, and it pays for the next step.
Week 1: Pick one process and measure it
List the repetitive work your team does every week. Then pick the one that scores best on these five questions:
- Does it happen often? Daily or weekly work pays back faster than a yearly task.
- Does it follow rules? "If the form says X, do Y" is a good fit. Work that needs fresh judgment every time is not.
- Does it eat real hours? Count them. Two hours a week across five people is ten hours.
- Is a mistake cheap to catch? Start where a person can check the result before it reaches a customer.
- Can you measure it? Hours spent, days to finish, errors found: pick one number.
Good first picks: sorting incoming requests, copying details between systems, drafting routine replies or quotes, turning call notes into tasks, and weekly reports built from spreadsheets.
Measure the baseline this week. Write down how long the process takes today and how often it goes wrong. Without this number, you won't know whether the change worked.
Week 2: Map the process and get the data ready
- Write every step as it really happens, not as the manual says. Sit with the person who does it.
- Mark each step as a rule ("always"), a judgment call ("it depends") or a hand-off to another person or tool.
- Find where the information comes from: an inbox, a form, a spreadsheet, a CRM. Choose one place as the source of truth.
- Gather 20 to 50 real examples, including messy ones. These become your test cases.
- Decide what the AI does and what a person still does. A common split: AI drafts, a person approves.
Leave anything sensitive out of the pilot (health, payment or ID details) unless the tool you'll use is approved for it. See our AI usage policy template.
Week 3: Build a small pilot
Pick the lightest option that can do the job. There are three levels:
| Option | Good for | Watch out for |
|---|---|---|
| An AI assistant with a saved prompt | Drafting, summarizing and sorting, where a person copies the result | Copy and paste stays manual; results depend on who writes the prompt |
| An automation tool connecting your apps | Moving data between tools that already have integrations | Gets fragile as rules pile up; limited to what the integrations allow |
| A custom tool | Work that spans several systems, needs your own data or is used all day | Takes weeks, not days; worth it once the process is proven |
Run the pilot on your test cases first, then on live work with a person checking every result. Keep a simple log: what went in, what came out, and whether it was right.
Week 4: Roll it out and decide
- Show the team how it works and what they still own. Write a one-page how-to.
- Compare the new numbers with your week 1 baseline.
- Collect the cases it got wrong and fix the rules or the prompt.
- Then decide: keep it as it is, build it properly, or move on to the next process.
Common mistakes
- Starting with the hardest process because it's the most painful. Start with the clearest one.
- Skipping the baseline, so nobody can say whether it helped.
- Letting AI send things to customers before a person has checked a few weeks of output.
- Buying a platform first and looking for a problem second.
- No owner. A pilot nobody owns quietly stops being used.
Questions
- Can a small business really do this in 30 days?
- Yes, for one process. The plan keeps the scope to a single, repetitive workflow and uses the lightest tool that works. Bigger systems take longer, but they go better once one process is proven.
- Do we need technical staff?
- Not for the first month. You need someone who knows the process well and can spend a couple of hours a week on it. If the pilot shows a custom tool is worth it, that's when a developer comes in.
- Which process should we start with?
- The one that happens often, follows clear rules, eats real hours, is cheap to check and is easy to measure. Sorting requests, copying data between systems and drafting routine replies are common first picks.