A small team cannot afford a pilot programme or a tool evaluator. So the decision has to be arithmetic. Here is the calculation, including the cost everyone forgets.
Advice about AI for small business tends to arrive in two flavours. Either a list of tools, which tells you nothing about whether any of them fits your work, or a warning about falling behind, which is not a business case.
A small team has no pilot budget and nobody whose job is evaluating software. The decision therefore has to be arithmetic, and the arithmetic is not complicated. It just has to include the parts people leave out.
Start with a task you actually do repeatedly. Time it honestly as it stands today, over a normal week rather than the worst week you remember.
Then run it with the tool for a week and measure two separate numbers.
The first is the time to produce. This is the one everybody measures, and it usually improves, sometimes dramatically. It is also the one that makes the tool feel transformative.
The second is the time to check and fix. This is the one that decides. A tool that halves production time and triples checking time has cost you time while feeling modern, and it will keep feeling modern right up until someone works out the total.
Add them. Compare to the original. That number, not the first one, is the effect on your week.
Against the time saved, put the whole cost of ownership.
The subscription, multiplied by the number of seats that will genuinely need it, not the number you hope to get away with. The hours somebody spends learning it well enough to get consistent results. The hours somebody spends keeping it working when it changes, because these products change often and without asking you.
And one more that is easy to miss: the cost of the tool becoming a dependency. In a small team, an automation typically has exactly one person who understands it. It survives precisely as long as that person stays. That is not an argument against building it, but it belongs in the calculation, and it argues for keeping things simple enough that someone else could pick them up.
A tool that saves two hours a month and costs a seat for each of eight people is not a saving. It is a subscription with a good story attached.
The pattern that holds up is narrow, repetitive work with a cheap and visible failure mode.
Turning a week of scattered notes into a structured document, where you were there for the week and can see immediately what is missing. Drafting the fifth version of a standard reply that a person then edits before it goes out. Pulling fields out of documents that arrive in a predictable shape, with someone reading the result before it matters. First pass triage of an inbox, where being wrong means a message gets read a little later rather than never.
What these share is that a mistake is cheap, obvious, and caught by someone who was going to look anyway.
It goes wrong where the output touches money or a legal commitment with no person in between. It goes wrong where the input arrives in a shape nobody controls, because unexpected input does not produce an error, it produces confident nonsense that flows onward. And it goes wrong where the person who built the thing is the only one who understands it.
There is also a particular trap in customer facing automation. A reply that is fast and slightly wrong is worse than a reply that is slow and right, because the wrong one has already been sent. Where a person would have hesitated, an automated step does not, and hesitation is often the valuable part.
Pick one task that passes the test. Run it for a month with the two measurements written down somewhere, not held in your head, because memory is generous towards things that felt fast.
At the end of the month, you will have a real number and a real answer for that one task. Then do the next one. This is slower than adopting a strategy, and it has the advantage of producing knowledge about your own business rather than about the software industry.
One last thing worth saying plainly: deciding that a task is better done by a person is a legitimate outcome of this exercise, not a failure of it. The point of measuring is to find out, and a measurement that only ever confirms the tool was not a measurement.
Three cheap models, 8 meetings, four transcript formats. They find 94.8 percent of the real actions. What they add is the problem: work cancelled during the meeting comes back on one list in five, with somebody's name on it.
Read the articleThree cheap models, 8 address books, four levels of mess. Finding duplicates is the easy part, 94.1 percent. The number that costs you a record is how often two different people get fused with nothing to warn you.
Read the articleThree cheap models, 24 invoices, four levels of messy text. Accuracy is the easy number. The one that costs money is how often a wrong extraction comes back with no warning at all.
Read the articleOne email when a new article is published. No tool of the week, no affiliate list, no forwarding of your address to anyone.
