AI automation for SMEs.

An automated process with AI always consists of the same four parts: a trigger, an input, a decision or transformation by a model, and an action in a system you already own. The model is only the third part — the value sits at the edges, in the fact that something starts by itself and the result lands automatically in the right place.

An example along those four parts. The trigger is a message in the general company inbox. The input is the free text with its attachments. The transformation assigns the message to one of a few categories, pulls out sender, object and requested date, and writes a draft reply. The action creates a case in the internal system and places the draft ready for approval. No step in that is spectacular; the saving lies in the fact that nobody sorts and retypes any more.

The boundaries matter in both directions. Downwards: if the input is already structured — a form with fields, an interface, a spreadsheet — no model is needed. Upwards: an agent that plans several steps on its own and calls tools is a considerably larger undertaking with considerably more review effort. For most SMEs the economic sweet spot is in the middle: one tightly scoped step with a clear beginning and end.

Technically what sits behind it is usually a language model with a narrow instruction, often extended by a connection to your own documents. That method is called retrieval augmented generation, and it is the reason a model can know your price list without ever having been trained on it.

As soon as a process can be described in sentences of the form "if … then …", classic automation without AI is cheaper, faster to introduce and more reliable — and in our conversations that applies to a substantial share of the wishes people bring. We say this at the start, because otherwise the alternative stops being considered the moment the word AI enters the room.

Solved rule-based and without a model, for example: appointment reminders and follow-up emails on a fixed schedule; handing form submissions into the CRM; recurring invoicing; payment reconciliation against reference numbers; dunning runs; automatic reports from existing data; data synchronisation between two systems with defined fields; approval paths with fixed responsibilities. Established tools exist for all of it, the results are reproducible and, in a dispute, fully traceable.

Three reasons argue clearly against a model in these cases. First, cost: rules run without usage-based fees. Second, auditability: a rule-based process is tested once and then holds; a model needs continuous sampling. Third, the shape of the failure. A rule breaks and the error is visible. A model, in case of doubt, produces a plausible but wrong output — and nobody notices until it does damage.

The pragmatic route is therefore almost always mixed: rules carry the scaffolding, and a model takes over exactly the place where unstructured text has to become structure. Do it the other way round and hand everything to a model, and you are paying for computation where a condition would have done.

The following six use cases come up most often in our conversations with SMEs, because they share one property: high volume, low complexity per case and a result that can be checked. The effort estimates describe the first introduction of a single process and do not replace a quote.

• Classify and route enquiries. Incoming emails or forms are assigned a category, given an urgency and passed to the responsible person. Effort: small to medium, because no interface to a specialist system is needed. Benefit: shorter response times and no enquiries left lying in a shared inbox.
• Read documents. Delivery notes, supplier invoices, orders or job reports are turned into structured fields and handed to accounting or the ERP. Effort: medium, most of it in the integration and the checking logic rather than in the model. Benefit: the classic retyping job disappears, and this process usually carries the highest volume in the business.
• Draft quotes and offers. From keywords, earlier projects and your own price list, a draft is produced that a specialist reviews and releases. Effort: medium, because the pricing logic has to be stored cleanly. Benefit: less time to the first quote, which in many industries co-decides who wins the job.
• Summarise conversations and meetings. Minutes, action lists and responsibilities come out of a recording or notes. Effort: small, provided the recording is cleared under data protection law and participants' consent is documented. Benefit: follow-up time drops noticeably and fewer actions get lost.
• Product and catalogue copy. Technical attributes become descriptions in a consistent tone, in several languages, in your shop's format. Effort: small to medium. Benefit: scales linearly with the number of articles, which makes it particularly economical in retail.
• Internal knowledge search. Staff ask in ordinary language about content from their own manuals, contracts or minutes and get an answer with a source reference. Effort: medium to large, because rights, currency and document quality all have to be sorted out. Benefit: high in businesses with many rule sets, low where documentation is thin.

What is deliberately missing from this list: anything that is immediately binding towards the outside world. Automatically sent price commitments, contract information or legal statements do not belong in the first stage. The related special case of customer dialogue has a page of its own: chatbot development.

An automation project starts with us not with a tool but with a process review — because that phase regularly reveals that the most expensive step is a different one from the step people wanted to automate. The sequence has five stages.

• Review. With the people who run the process daily we walk through every step: trigger, systems involved, exceptions, frequency, time needed. Exceptions are the most important part, because they determine the review effort later.
• Prioritisation. Each candidate is scored on frequency, time per case and the cost of an error. Whatever happens often, costs little time and is harmless moves up; whatever happens rarely and is expensive when it goes wrong stays with people for now.
• Pilot. Exactly one process gets built and tested against real historical cases, not sample data. A validated prototype starts with us at CHF 10'000; the range depends on interfaces and data quality.
• Measurement. Results are compared against a baseline recorded before the start: throughput time, error rate, share of cases that needed a correction. Without that measurement, every later statement about benefit is an assertion.
• Operation. Handover to a responsible person in the business, a sampling rhythm, logging, and a fixed interval at which prompts, categories and thresholds are updated.

If the review makes clear that a process mainly suffers from missing data or unclear responsibilities, we stop and say so. Those questions belong in consulting and not in a development project; the wider perspective sits in our article on digital strategy for Swiss SMEs.

Budget for three separate blocks: the one-off introduction, the running usage-based model costs and the maintenance effort — calculate only the first and you will underestimate the total systematically. The build is rarely the expensive part; three years of operation is.

Introduction covers the process review, the connection to existing systems, prompt and rule work, the review interface and testing on real cases. With us a validated prototype starts at CHF 10'000; what pushes it upwards is mainly how many systems are involved and how well their interfaces are documented. Running model costs depend on the volume and length of the texts processed and, for the use cases described here, are usually the smallest item. Maintenance is the block most often forgotten: categories change, forms change, providers update models, and every one of those changes calls for a re-check.

For the benefit side a simple calculation you can do yourself is enough: cases per month, times minutes saved per case, times your internal hourly rate, minus the running costs. If twelve months of that come to less than the introduction, the case is not ready. If it comes to a multiple, it is.

One caveat belongs with it, and it is the most important sentence in this section: saved time is not a saved cost item as long as it is not spent on something else. Twenty minutes saved per day, spread across eight hours, vanish into the working day if nobody decides what they are for. The benefit that holds up therefore usually sits elsewhere: more volume handled without additional staff, faster response times and fewer transcription errors. Those three figures can be measured and demonstrated afterwards.

Before the first process goes live, three points have to be settled: which personal data passes through the process, where it is processed, and whether your privacy policy already describes this activity. The revised Data Protection Act has applied since 1 September 2023 and requires adequate information to the people concerned under Article 19 FADP whenever personal data is collected.

In practice that means four things. First: a provider processing data on your behalf is a processor under Article 9 FADP; that needs a contractual basis and assurance that the provider guarantees the same data security you owe yourself. Second: if data goes abroad, Article 16 FADP applies — either to a country with adequate protection under the annex to the data protection ordinance, or on the basis of suitable safeguards such as standard contractual clauses. Third: a record of processing activities is mandatory; companies with fewer than 250 employees are exempted by ordinance provided the processing carries only a low risk to personality rights. Fourth: settle contractually whether your inputs may be used to train models — business offerings usually exclude this, free tiers often do not.

Automated individual decisions are a point in their own right. Where a decision with a legal consequence or a significant adverse effect is taken exclusively by automated means, Article 21 FADP applies, with a duty to inform and a right to state one's position and have the decision reviewed by a human. For job applications, credit or contract decisions that means: preparation by a model yes, sole decision no.

Switzerland has no AI act along EU lines. In February 2025 the Federal Council decided to ratify the Council of Europe AI Convention and implement it sector by sector; a consultation draft is announced for the end of 2026. Anyone serving customers in the EU should additionally check the EU AI Act, whose transparency duties under Article 50 have applied since 2 August 2026. The orientation here does not replace legal advice.

In five situations we advise against an automation project, and we do so before a quote is written. Each of them leads in practice to a solution that gets switched off within months.

• The process is not stable. If three people run the same process differently, you are automating one of three variants. Decide first, automate second — that is organisational work, not technology.
• The volume is too small. Below roughly fifty cases a month, the introduction and maintenance effort almost always exceeds the benefit. A well-built form or a template solves the problem better then.
• Checking costs as much as doing. In processes with high error costs, every result has to be reviewed. If the review takes as long as doing the work by hand, no advantage is left.
• The data does not support it. A model cannot answer from documents that are out of date, contradictory or simply absent. Internal knowledge search fails on exactly this, regularly, and not on the technology.
• Nobody is responsible. Without a named person to sample results and report errors, every automation is orphaned. That is the most common reason working solutions get turned off again.

And a sixth point, which is not a situation but a sequence: if your website brings in no enquiries today, automating enquiry handling is the wrong first project. The leverage then sits upstream — in being found and in the offer itself. For that there is ongoing SEO, GEO for visibility in AI answers and, if the website itself is the bottleneck, the sober assessment under building a website with AI.

We are a small digital agency with our own development team in Zollikon; we build automations ourselves instead of handing over a plan of measures. Our working basis is our own web applications: the project calculator, the configurator and the SEO check on this website are in-house builds and show how we structure input, logic and output.

What we do not claim: we keep no list of AI automation projects with percentage figures attached. Our documented work sits in web development, e-commerce, SEO and marketing — you can read it under work — and it includes a web application for tax returns, not an AI automation mandate. Anyone showing you a long reference list with hard savings figures in this still young field should be asked how those figures were gathered and against which baseline.

What you can check instead: whether we understand the process before naming a tool; whether we examined the rule-based alternative; whether a metric was fixed before the start; and whether we tell you when the project is not worth doing. For the strategic assessment without implementation there is AI consulting, and for mandates with a Zurich connection the page on the AI agency in Zurich. If the process needs an agent rather than a single step, that is described under AI agent development.