How to automate a business process without buying another platform
Most small businesses have two or three jobs that run every week, follow a set of rules, and take hours. This is how I go about choosing one of them, what the software already in the building will do, and where AI is the wrong tool for the job.
What "automating a process" means in a small business
In a large company, business process automation arrives as a platform with a workflow builder and a person employed to look after it. In a company of fifteen people it looks much smaller than that: a scheduled job that builds the month-end figures, or a form that drops an enquiry into the CRM already tagged with where it came from. Either way the work is software carrying out a sequence of steps somebody currently carries out by hand.
The unit is the process, not the department. A process worth the name runs on a trigger and produces an output somebody downstream depends on, with the steps in between happening in much the same order each time. Where the order shifts according to judgement that only lives in one person's head, there is no process yet, and writing it down is the first piece of work.
Automation does not have to be total, and mostly it should not be. Most of what I build takes away the fetching and the reformatting and leaves the decision with a person. The report assembles itself overnight and somebody reads it before it goes anywhere. That division is easier to trust than a process running unattended from its first week, and it is easier to unpick when a number looks wrong.
None of this needs a new product in the ordinary case. A small business is already paying for a CRM, an accounts package, a file store and a chat tool, and most of the wiring runs between things it owns.
How to find the process worth automating first
The first process to automate is rarely the one that annoys people most. It is the one where frequency meets stability. A task that runs every week, takes a couple of hours, and has not changed shape in a year is worth more than a painful quarterly exercise that gets done differently every time.
The measurement is cheap. Ask the two or three people doing the most repetitive work to keep a rough log for a week: what they did, and which systems they had to open to do it. The systems column is the useful one. A task that touches four applications is usually a task where a person is acting as the integration between them.
Then rank what comes back. Time saved per month is the obvious axis. The second axis is how badly a mistake would hurt, because that decides how much checking has to stay in the loop. A process that quietly sends a wrong figure to a customer sits in a different category from one that produces an internal summary nobody acts on directly.
Do one at a time. A programme that sets out to automate a department spends months in analysis and delivers nothing anyone can look at. That is the reasoning behind starting with discovery and a single-process pilot: one process, real data, in front of the people who own it, inside a few weeks. The second one is much faster than the first, because by then the access and the plumbing already exist.
The processes that are a poor fit
The processes to leave alone get far less attention than the candidates. That list is the shorter of the two, and paying attention to it saves more money. Four categories come up repeatedly.
Judgement with no written rule
Where a decision rests on knowing a customer's history, or on a sense of whether a supplier will be difficult, the rule cannot be written down, so it cannot be encoded. These are still worth helping: gather the information, put it in front of the person, and leave the call with them.
Rare, and expensive to get wrong
Something done four times a year by a person who knows it well is a poor return. The build costs the same as it would for a weekly job, the saving is a twelfth of it, and nobody will remember how the automation works by the time it next runs.
Unstable inputs
A process fed by a spreadsheet whose columns get renamed, or by a supplier file that changes format every few months, breaks constantly. Stabilise the input first. Occasionally the fix is asking the supplier for an export with fixed headers, which is a phone call and not a project.
A process that is already broken
Automating a bad process makes it produce bad output faster. Where the weekly report exists because somebody asked for it years ago and nobody reads it now, the correct automation is to stop producing it. Much of the value in looking at how work gets done lies in finding tasks that can simply be deleted.
There is a fifth category worth naming, because it hides inside the others: anything where the real problem is that the underlying data is wrong. Automation carries an error along at speed and lends it the authority of having come out of a system. The fix there is upstream, in whatever produces the data, and it has to happen before any of this is worth building.
What the existing subscriptions already cover
Most small businesses are paying for more automation than they use. A Microsoft 365 or Google Workspace subscription includes a limited tier of workflow automation already, and form-to-spreadsheet routing at no extra cost. A CRM sold to a company of twenty almost always has a workflow builder inside it that was configured once during onboarding and never opened again. Accounting packages such as Xero have bank rules and recurring invoices that remove a surprising amount of manual keying.
An afternoon walking through the admin settings of every tool in the stack is worth spending before anything gets built. Now and then the answer to a whole process is a feature that is already paid for and switched off.
After that comes the light glue. Zapier, Make and Power Automate connect two systems that both have an API, on a trigger, and they are good at moving a record from one place to another and telling somebody it happened. They get expensive and awkward once a workflow grows branches, and they are hard to read six months later when nobody remembers why a particular step is there.
Past that point a small script on a schedule is often simpler than the visual equivalent. I have built connectors into Xero, HubSpot, Mailchimp, Toggl and Microsoft 365 for that reason: once the plumbing is code, the awkward cases stop being blockers. It is mainly a decision about who maintains the thing afterwards.
What AI adds, and where plain automation is better
AI earns its place where the input is unstructured. A rule can move a number from one column into another. It cannot read forty supplier emails and work out which two mention a price change. Language models are good at pulling structure out of documents and transcripts, at sorting things where the boundary between categories is fuzzy, and at drafting text a person will then edit.
The second thing they add is a plain-language interface. Someone asks for a figure in a sentence and gets it back, without having to learn where the report lives or what the filter is called. That removes most of the training problem, which is usually the expensive part.
For everything else, rules are better, and it is worth being blunt about why. A rule returns the same answer every time and costs nothing per run. Whoever inherits it can read it, and when it breaks it breaks loudly and in one place. A model given the same input twice can produce two slightly different outputs, which is fine for a summary and not fine for a figure going onto an invoice.
So the rule of thumb is this: where the logic can be written down as a set of conditions, write it as conditions. Reach for a model where the input is language, or where the number of edge cases would make a rule tree unmaintainable. A fair amount of what gets sold as AI automation is a scheduled job with a model bolted onto the front, and the scheduled job is doing most of the work.
Cost and speed follow the same line. A model call adds seconds and pennies to every run. On a process that fires twice a day that is irrelevant. On one that fires ten thousand times a day it decides the design.
Worked examples: reporting, data entry, answering from internal documents
Three examples at the scale this page is about. Each one is narrow, and none of them needed a new system to sit in.
Reporting that assembles itself
The usual version has somebody spending a morning each month exporting from four systems, pasting into a template, and writing the commentary at the end. The exports are all API calls, and the join is a scheduled job writing into a sheet the team already opens. What survives is the commentary, which is the part with judgement in it.
Reports are only worth automating where the figures feeding them are sound. On the marketing side that means the tracking underneath the reporting has to be right before any of it is built.
Data entry between systems
Two systems holding the same customer records, kept in step by a person, is the most common automation in a small business. Where both have an API it is a solved problem. Where one does not, the honest answer is sometimes that a person carries on doing it, or that the tool gets replaced at renewal. A related case is meeting notes: transcription tooling turns a call into a summary and a list of actions, and the CRM entry is written from that, not from somebody's memory the following day.
Answering questions from internal documents
Policies, contracts, price lists and process notes end up scattered across a shared drive, and the same handful of questions get asked in the same channel every week. An assistant with read access to that drive answers from the documents and says which one it took the answer from. The citation is what makes it usable, because the person can go and check. Most of the connectors and tools I have built follow that shape: narrow access to one real system, questions asked in ordinary language, and an answer that can be traced back to its source.
Building it into Slack or Teams, not another dashboard
Where an automation lives decides whether it gets used. A dashboard is somewhere a person has to remember to go, and remembering is the step that fails. A message in the channel a team already has open arrives whether anyone remembered or not.
So the output goes where the work already happens. The weekly summary posts into the channel. The exception report tags whoever owns it by name. Where a question needs answering, the same channel takes the question, which is the thinking behind putting AI agents in the tools a team already uses.
The heading at the top of this page needs one qualification. Software is often worth buying: a business with no CRM should buy a CRM, and a business outgrowing spreadsheets for stock should buy something built for stock. The claim here is narrower. For a company already paying for four or five systems, the gap is usually in the connections between them, and a new platform adds a sixth login while leaving that gap where it was. Buying makes sense for systems that hold data. The layer that sits between them is glue, which costs little to build and little to alter afterwards.
Getting people to actually use it
The build is finished, the thing works, and three weeks later two people are still doing the task the way they did it before. The old way is what their hands know, and a working system does not on its own change that.
A few things help. The new route has to be the default and not an option running alongside the manual one, because where both exist the manual one wins. Whoever does the task now should see the build early enough to change it; a process handed down finished gets treated as somebody else's. Naming an internal owner matters more than the documentation does, meaning one person who understands what the thing does and is allowed to say when it is wrong.
Failure has to be visible. A job that quietly stops running is worse than no job at all, because people carry on trusting an output that is no longer being produced. Everything I build on a schedule says something when it fails, into the same channel as its normal output, and a run that produced nothing at all is worth announcing too.
My own background is organisational psychology before it was anything technical, and this is the part of the work that draws on it. Whether the tool is any good is only part of whether it is still in use six months later.
Handover: documentation, access, and what happens when it breaks
Anything built for a business that does not employ engineers has to survive the person who built it walking away. In practice that means the access sits with the company and there is a written record of what runs and when.
Access first. API keys, service accounts and the automation's own logins belong in the company's password manager, under accounts the company owns, not on a consultant's personal profile. It is worth settling at the start, because retrofitting ownership onto a service account after the fact is tedious and occasionally impossible.
Documentation for this kind of work is short. What runs, when it runs, what it touches, and what to do when it stops. A single page usually covers it. The tools I have handed to non-technical colleagues came with a plain description of the inputs and the outputs and nothing about the internals, because nobody needed the internals until something changed.
Things do break, and the causes are dull. An API version is retired. A token expires. Somebody renames a column in the source spreadsheet. A supplier changes their export format without telling anyone. None of that is an emergency where the process has a manual fallback and the failure announces itself, which is why both of those matter more than clever design. Who fixes it should be agreed before the first failure, whether that is an internal person, the original builder, or nobody at all, on the understanding that the task reverts to being manual until it is fixed.
The finished state is a process the business can explain and switch off without ringing anyone. Anything short of that stays a dependency on an outside party.
First steps and running costs
Where should a small business start with automation?
With one task that comes round every week, follows rules somebody can state out loud, and touches more than one system. A week of rough logging by the people doing the repetitive work usually surfaces it. Anything that needs a department-wide review before it can begin is too large for a first attempt.
How much does it cost to automate a process?
Mostly it depends on whether every system in the chain exposes an API. A scheduled job between two well-documented APIs is a small fixed piece of work. A process that depends on a tool with no API can cost more to work around than the manual version costs to keep, which is a legitimate reason to stop.
Do I need AI to automate a business process?
Usually not. Anything whose logic can be written as conditions belongs in a scheduled job, which is cheaper per run and predictable. A model earns a place when the input is language: documents, transcripts, free-text email, or categories with fuzzy edges.