AI automation for SMBs is useful when a model can help complete a specific step, such as categorising a request or finding information in documents. Start with work that gets stuck or repeatedly needs retyping. Then decide whether AI is needed and who checks the result. For the concepts, read about AI agents and chatbots and using AI with your own documents.
What is AI automation, and when are fixed rules enough?
In AI automation, a model performs a task within a larger process. It might classify free text or prepare a draft. Ordinary automation follows predefined rules. If you only want to route an invoice using a known customer number, a rule may be enough.
The distinction between a workflow and an agent concerns who chooses the route. Workflow steps are defined in advance; an agent’s model chooses subsequent steps and tools within the available capabilities. Anthropic describes this distinction and recommends starting with the simplest approach that can handle the task.
As a buyer, pay attention to the freedom the application receives. A system that makes a suggestion needs different permissions from one that changes an appointment. More independence is only useful if the task needs it and you can follow what happens.
| Work to perform | Possible approach | What should you check? |
|---|---|---|
| Transfer data using a fixed identifier | Rule or ordinary integration | Is the identifier correct, and has processing already happened? |
| Categorise an email by subject | Text classification model | When is the category unclear? |
| Answer a question from documents | Retrieval plus a model-generated answer | Do sources support the answer, and may the user see them? |
| Prepare a customer reply | Model drafts a response | Who checks facts, tone and commitments? |
| Choose follow-up actions across systems | Bounded agent | Which actions are permitted, and where is approval required? |
Which task should your business start with?
Choose work whose outcome you can assess. ‘Automate our administration’ is too broad for a focused test. ‘Categorise incoming requests and draft a message asking for missing information’ gives you something to demonstrate, correct and compare with the current process.
Involve the people doing the work. They know the email with a second request halfway through it, the customer number that doesn’t match and the exception nobody has documented. A process that looks clear on paper may depend on that knowledge. Write down those decisions before handing them to software.
Assess candidate tasks by recurrence, available inputs, reviewability and the consequences of an error. You don’t need an artificial scoring system. For each task, ask whether a mistake can be spotted before anything is sent or changed. If not, the review arrangement needs more attention than model selection.
Sometimes the problem isn’t a lack of automation. If staff use different versions of a price list, first agree which version applies and who maintains it. Giving both to a model doesn’t resolve that ownership question.
What does a clearly defined workflow look like?
Take a hypothetical example: a service business receives requests by email. Staff want to see sooner whether a message concerns a fault, a quotation or an existing appointment. In the first version, the model only suggests a category and draft summary. A person reviews those suggestions; no customer message is sent yet.
Ordinary process rules sit around that step. The application records the incoming message, checks whether it has already been processed and attaches the result to that message. If an attachment is missing or the text can’t be read, the request joins a manual queue. Staff should be able to open the original email without searching again.
Also test a message containing several subjects. Should the system choose one category or suggest two tasks? What happens with an empty email, a forwarded conversation or an attachment belonging to another customer? These questions shape the application. Writing a good prompt alone won’t answer them.
Only once that initial process proves useful should you discuss the next step, such as creating a draft task in the scheduling system. That requires its own permissions and checks. Permission to read text doesn’t automatically allow a change to an appointment.
Which real projects illustrate the possibilities?
For BBS Advocaten, we built a content process that follows court RSS feeds and filters rulings by categories and keywords. Selected material becomes a blog post, summary and social post in the firm’s house style. Uploaded PDFs can follow the same route. This case concerns content processing, rather than a system independently handling client matters.
At Planit Consulting, the application searches the firm’s document archive and answers questions with source references. That’s a different goal from automatically sending messages or changing records. The user’s question here is whether they can find relevant information and check the answer against its original document.
Treat these cases as examples of scope. They don’t establish that the same setup will save the same amount of work elsewhere. Your source quality, permissions and working practices determine what needs testing first.
Should you choose an existing tool, no-code or custom development?
Start with features your current systems already offer. If an existing package can perform the task with the required permissions and checks, you needn’t rebuild that function. Trial it with your own process: a product demonstration won’t necessarily include the exceptions from your administration.
A workflow platform may suit connecting existing services and building a predefined route. Check which operations its connectors support, how you investigate errors and who maintains the flow. Our comparison of Zapier, Make and n8n helps you explore the options; check current functions and terms with the vendor.
Custom development is an option when the required behaviour or user experience doesn’t fit well enough. It can also be a limited addition to an existing system. You don’t need to replace your entire administration to improve one difficult process. Our explanation of no-code and custom automation explores that decision further.
Ask the same question of every route: who can understand and repair the process when its original maker isn’t available? Request a description of the steps, access to settings and a way to inspect failures. A visual flow doesn’t maintain itself any more than a custom application does.
How do you arrange data access and human review?
Map which data the application reads, where it goes and who may use it. Include logs, temporary files and backups. A model needn’t receive an entire customer record if the task only requires one request’s text. Limit the data flow according to the task.
For personal data, assess matters including purpose, lawful basis, necessary data and security. If a supplier processes personal data on your behalf and under your instructions, you need a data processing agreement. The Dutch government business portal’s GDPR checklist covers these obligations. Choosing a server location or signing an agreement doesn’t, by itself, make the whole application compliant.
A DPIA is required where processing is likely to create a high privacy risk. It isn’t automatically required for every use of AI. Assess the need before processing begins; Ondernemersplein explains when a DPIA is required.
Make human review specific. ‘A person remains involved’ means little if nobody has time or knows what to check. For example, show the draft beside the original request, flag missing information and give the reviewer clear choices to approve, amend or return it. Retain enough information to investigate a wrong action without unnecessarily copying whole records into logs.
Reading needs boundaries too. Someone who may not open a particular file shouldn’t receive its contents through a summary either. Test the application using different roles, not only an administrator account with access to everything.
How do you know whether the automation works well enough?
Define a useful result before starting the trial. For text classification, that might mean a correct category and a recognisable route for uncertain cases. A draft response also needs assessment of its facts and commitments. Choose criteria for the task; one overall accuracy percentage can hide the types of error behind it.
Use representative examples and keep some aside for the final assessment. If every adjustment is checked against exactly the same familiar examples, you mainly learn whether the application has been fitted to those cases. Ask the people who do the work to assess results too. They can identify an answer that’s technically correct but unusable for the next step.
Measure the whole process. Record time to a usable outcome, manual corrections and tasks that never get completed. Include outages: can people see that work is waiting, and can someone take over temporarily? A fast model response has little value if an integration then fails unnoticed.
Agree a decision point. Continuing might mean allowing more usage, but it could also mean narrowing the task or sticking with fixed rules. A trial is useful when its result can change that decision.
Which costs and maintenance tasks remain?
Budget for preparation, development and introduction separately from daily use. Recurring items may include model calls, hosting, external services and maintenance. Include your own team’s work. The guide to AI agent costs provides a calculation method with a dated token example; the model bill is only part of the total.
Don’t expect a fixed saving based on a generic demonstration. Compare current handling with the trial, including review and corrections. Time released may help with other work without immediately reducing payroll. Name the improvement you expect: less duplicate entry, a shorter queue or quicker access to information.
After delivery, the application needs an owner. That person maintains sources, examines deviations and decides on changes. Retest when relevant data, instructions, models or integrations change. Also agree how to return to the previous working method if an update goes wrong.
With TopDevs custom development, the code is and remains yours. Handover also needs documentation, settings and access to the services involved. Record this alongside maintenance arrangements so your team or another supplier knows what’s needed to continue the work.
How do you actually get started?
Describe one recurring task, including inputs, the intended outcome, exceptions and a responsible member of staff. Then collect examples for assessing whether a proposal works. Don’t enable automatic follow-up actions before deciding what consequences a mistake could have and how to handle them.
If you want to commission AI automation, we’ll use that scope as the starting point. First establish what the application should do and what the trial must demonstrate. Book a call to discuss the first task.
