To decide what a small business can automate on a small budget, I start with the work as it happens today. What arrives, who checks it, where information gets copied and what happens when a field is missing. Then I compare the work we could remove with the work that will remain: supervision, exceptions and maintenance.
You do not have to start with AI. A reminder, a scheduled export or a rule in your existing tool may solve the problem. Custom development makes sense when existing options leave a specific gap and the business can support the resulting system.
Tasks I would put on the first shortlist
I would look for repeated tasks with an outcome a person can check: preparing an internal report, creating a task from a form, flagging pending requests or moving approved fields between tools. These are candidates to assess, not promises of savings.
- Reports: gather available data and flag incomplete sources before distribution.
- Requests: check required fields, assign an owner and show what is still pending.
- Documents: prepare classification or extraction for review where the format allows it.
- Follow-up: remind someone of an internal task without sending a customer an unapproved answer or commitment.
Before adding text generation, I would review the limits of applied AI in production. If the task requires web data collection, data pipeline architecture comes later: first justify the source and its maintenance.
A worksheet for prioritizing automation
Complete this worksheet for each candidate using samples of actual work. Include ordinary days and known exceptions. Mark missing information as unknown; do not turn it into zero or an optimistic estimate.
| Criterion | What to record | How it affects the decision |
|---|---|---|
| Current workload | Cases per period, active work time and corrections. | Frequency alone does not prove value. Separate work from waiting time. |
| Rules and exceptions | Repeated steps and decisions that vary by person. | Agree missing decision rules before writing code. |
| Data and access | Required fields, source, permissions and access method. | A stable export may be enough; an uncertain dependency needs investigation. |
| Consequence of error | What changes, who notices and how it is corrected. | Prefer a reviewable output for the first pilot. |
| Remaining work | Review, exceptions, support and changes to tools. | Count the team's effort after automation. |
| Owner and measure | Who accepts the output and what improvement they need to see. | Without an owner or measure, the candidate is not ready. |
I would not add up scores to hide a blocker: high volume cannot compensate for missing access or an inability to review mistakes. Among viable candidates, I would choose the one that lets us verify a useful improvement with the smallest scope and dependencies we can maintain. If the project is still not viable, see when I redesign or reject an automation project.
A hypothetical choice: reports, requests or replies
Imagine a small business with three candidates: a weekly report, requests submitted through a form and commercial replies drafted from free-form emails. This is a hypothetical example, not a client case or a universal ranking.
If the report uses stable exports, agreed rules and a reviewer, I would start by generating a draft that flags missing data. Publishing would remain manual. Request routing could follow if the team still needs to agree who handles each request type. I would postpone autonomous commercial replies if they depend on availability and prices that nobody keeps current.
The choice would change if the report takes almost no work and requests cause measured delays. The worksheet exists to establish that difference before buying tools.
What to leave out of the first pilot
Define one input, one output, a user group and an exception owner. Record exclusions too: historical migration, new channels, external replies, pricing decisions or a full dashboard do not have to be part of the first engagement.
First check whether an existing tool feature covers the workflow. If development is needed, ask for the smallest flow with execution records, failure alerts and a way to stop it. An incomplete result should wait for review instead of appearing complete.
The Adslyfy case study shows executions, failures and screenshots in ad monitoring. It demonstrates operational visibility; it does not establish an economic return for this example or require you to copy its architecture.
How to evaluate whether the pilot is worthwhile
Compare an agreed set of equivalent cases before and after. Record completed cases, pending work, errors and the team's active work time. Include data preparation, review and failure recovery; do not measure machine execution time alone.
Net time released in the period = comparable manual work − pilot preparation, review, exception handling and maintenance. Track customer or team waiting time separately: reducing it can matter even if it does not remove working hours.
Separate the initial investment from recurring tool, execution and support costs. Released hours create capacity; they do not automatically reduce payroll. With low volume or no representative exceptions, the result may be inconclusive. You need more evidence rather than a return-on-investment promise.
- Continue: the agreed goal is met, the owner can operate the workflow and recurring costs are acceptable.
- Adjust: the output is useful, but review or failures consume more effort than expected.
- Stop: the process keeps changing, the team does not use the output or cannot maintain it.
- Measure more: there are not enough cases to decide. Agree an effort limit and another review.
What to bring before requesting a quote
Prepare the current workflow, samples without sensitive data, available tools and access, the candidate worksheet and the exclusions. Ask the proposal to identify who configures, tests, reviews and maintains each step. My guide to comparing software quotes covers that purchasing decision.
My business process automation service explains how I agree scope, deliverables and acceptance. If the blocker involves priorities and technical decisions across the team, consider fractional CTO support.
Choose the first process with a concrete scope
If you are considering automation for your business, tell me how the current process works, which work repeats and who would review the result. That gives us a basis for deciding what to test, what should remain manual and what still needs measuring.