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 choose one, what the software already in the building will do, and where AI is the wrong tool.
What "automating a process" means in a small business
In a large company, process automation arrives as a platform with a workflow builder and a person to look after it. In a company of fifteen it is a scheduled job that builds the month-end figures, or a form that drops an enquiry into the CRM tagged with its source. Software doing steps somebody currently does by hand.
The unit is the process, not the department. A real process runs on a trigger, follows much the same steps each time, and produces an output somebody depends on. Steps that live as judgement in one person's head are not a process yet; writing them down is the first piece of work.
Automation does not have to be total, and mostly should not be. I take away the fetching and reformatting and leave the decision with a person: the report assembles itself overnight, somebody reads it before it goes out. Easier to trust, and easier to unpick when a number looks wrong.
It rarely needs a new product. A small business already pays for a CRM, an accounts package, a file store and a chat tool; 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 weekly two-hour task unchanged in a year beats a painful quarterly exercise done differently every time.
Finding it is cheap:
- Ask the two or three people doing the most repetitive work to log a week: what they did, which systems they opened. A task touching four applications usually means a person is the integration between them.
- Rank the results by time saved per month.
- Rank again by how badly a mistake would hurt, which decides how much checking stays in the loop. A wrong figure sent to a customer is a different category from an internal summary.
Do one at a time. A programme that sets out to automate a department spends months in analysis and delivers nothing. Hence discovery and a single-process pilot: one process, real data, in front of its owners, inside a few weeks. The second is faster, because the access and plumbing already exist.
The processes that are a poor fit
The processes to leave alone get less attention than the candidates, and paying attention to them saves more money. Four categories come up repeatedly.
Judgement with no written rule
Where a decision rests on knowing a customer's history, or a sense of whether a supplier will be difficult, the rule cannot be written down, so it cannot be encoded. Still worth helping: gather the information, put it in front of the person, 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 a weekly job, the saving is a twelfth of it, and nobody remembers how it works by the next run.
Unstable inputs
A spreadsheet whose columns get renamed, or a supplier file that keeps changing format, breaks the process constantly. Stabilise the input first. Sometimes that is asking the supplier for fixed headers: a phone call, not a project.
A process that is already broken
Automating a bad process makes it produce bad output faster. Where nobody reads the weekly report any more, the correct automation is to stop producing it. Some tasks can simply be deleted.
A fifth category hides inside the others: wrong underlying data. Automation carries the error along at speed and lends it the authority of a system. The fix is upstream, and it comes first.
What the existing subscriptions already cover
Most small businesses pay for more automation than they use. An afternoon in the admin settings of every tool in the stack is worth spending before anything gets built. Usually already there:
- Microsoft 365 and Google Workspace include a limited tier of workflow automation and form-to-spreadsheet routing at no extra cost.
- A CRM sold to a company of twenty almost always has a workflow builder, configured during onboarding and never opened again.
- Accounting packages such as Xero have bank rules and recurring invoices that remove a lot of manual keying.
After that comes the light glue. Zapier, Make and Power Automate connect two systems that both have an API, and are good at moving a record and telling somebody it happened. They get expensive once a workflow grows branches, and hard to read six months later when nobody remembers why a step is there.
Past that point a small script on a schedule is often simpler. I have built connectors into Xero, HubSpot, Mailchimp, Toggl and Microsoft 365 for that reason: once the plumbing is code, awkward cases stop being blockers. The real decision is who maintains it 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 between columns; it cannot read forty supplier emails and spot the two mentioning a price change. Language models are good at:
- pulling structure out of documents and transcripts
- sorting things where the boundary between categories is fuzzy
- drafting text a person will then edit
- answering plain-language questions, so nobody learns where the report lives
The last of those removes most of the training problem, usually the expensive part of a rollout.
For everything else, rules are better:
- the same answer every time, at no cost per run
- whoever inherits it can read it
- when it breaks, it breaks loudly and in one place
A model given the same input twice can produce slightly different outputs. Fine for a summary, not for a figure on an invoice.
So: where the logic can be written as conditions, write it as conditions. Reach for a model where the input is language, or where edge cases would make a rule tree unmaintainable. A lot of what gets sold as AI automation is a scheduled job with a model bolted on.
A model call adds seconds and pennies to every run. Irrelevant twice a day. At ten thousand runs a day it decides the design.
Worked examples: reporting, data entry, answering from internal documents
Three examples at this scale. None needed a new system to sit in.
Reporting that assembles itself
Somebody spends a morning each month exporting from four systems, pasting into a template, and writing the commentary. The exports are API calls; the join is a scheduled job writing into a sheet the team already opens. The commentary survives; that is where the judgement is.
Only worth building where the figures are sound; on the marketing side the tracking underneath the reporting has to be right first.
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, sometimes a person carries on, or the tool gets replaced at renewal.
A related case: transcription turns a call into a summary and a list of actions, and the CRM entry is written from that, not from memory the next day.
Answering questions from internal documents
Policies, contracts and price lists scatter across a shared drive, and the same questions get asked every week. An assistant with read access answers from the documents and says which one it used, so the person can check.
Most of the connectors and tools I have built follow that shape: narrow access to one system, plain-language questions, answers traceable to a 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 a channel the team already has open arrives regardless.
So the output goes where the work happens. The weekly summary posts into the channel. The exception report tags its owner. The same channel takes questions, which is the thinking behind putting AI agents in the tools a team already uses.
One qualification to the heading: software is often worth buying. A business with no CRM should buy a CRM; a business outgrowing spreadsheets for stock should buy something built for stock. Buying makes sense for systems that hold data.
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 it there. The layer between systems is glue, cheap to build and cheap to alter.
Getting people to actually use it
The build is finished, the thing works, and three weeks later two people still do the task the old way. The old way is what their hands know, and a working system does not on its own change that.
What helps:
- Make the new route the default, not an option alongside the manual one. Where both exist, the manual one wins.
- Show the build to whoever does the task early enough to change it. A process handed down finished gets treated as somebody else's.
- Name an internal owner: one person who understands the thing and can say when it is wrong. That matters more than the documentation.
- Make failure visible. A job that quietly stops is worse than no job, because people keep trusting an output that no longer arrives. Everything I build on a schedule reports its own failure into the channel its output normally goes to.
My background is organisational psychology before anything technical, and this is the part that draws on it. Whether the tool is good is only part of whether it is in use six months later.
The same applies to the notes around a process: the shared folder my own team runs on worked because the convention was easier to follow than to ignore.
Handover: documentation, access, and what happens when it breaks
Anything built for a business without engineers has to survive the builder walking away: 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 a consultant's personal profile. Settle this at the start; retrofitting ownership later is tedious and occasionally impossible.
Documentation is short: what runs, when, what it touches, what to do when it stops. A page usually covers it. Nobody needs the internals until something changes.
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 a manual fallback exists and the failure announces itself. Agree who fixes it before the first failure: an internal person, the original builder, or nobody, with the task reverting to manual until fixed.
The finished state is a process the business can explain and switch off without ringing anyone. Anything less stays a dependency on an outside party.
The remaining guides deal mostly with tracking and measurement; they are on the guides page.
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 work usually surfaces it. Anything that needs a department-wide review first 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 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.