A·01
Documents and invoices
PDF in, structured data out: supplier, total, due date, line items, a posting suggestion. The machine reads and writes, a human approves.
Service · AI automation and integrations
AI-
automaatio
Repetitive work that eats hours every week can usually be automated. AI automation here means that a language model handles the part rule-based automation never could: reading, classifying and summarising free text. The rest is ordinary integration work.
Free scoping call · pilot in 1 - 2 weeks
[ 01 ]
What it actually is
Two different things get mixed up constantly: rule-based automation and AI. Most of the benefit comes from data moving between systems without anyone copying fields by hand. That needs no model at all.
The model is needed only where the content is free text: invoice rows differ per supplier, a customer message is written in human language, a product description has to be produced for a thousand items. Rules do not cover those.
If the problem is solvable without a model, it gets solved without a model. The model is the most expensive and least predictable part of the pipeline, so it is used only where it is the only option. That is also the cheapest way to build: the smaller the model's share, the more predictable the result.
[ 02 ]
Where it fits
A·02
Customer messages
Incoming messages classified by topic and urgency, routed to the right person, with a draft reply waiting.
A·03
Product data and content
Product descriptions, translations and search metadata for a whole catalogue. The same job that by hand never gets finished.
A·04
System integrations
CRM, web shop, invoicing and Slack in one pipeline. No model needed in this part, which is exactly why it is worth doing first.
[ 03 ]
Automations in production
These are running, not built for a demo. Both started from a need of my own, and in both the model is handed exactly the part nothing else can do.
A·01
Outreach pipeline
Finds businesses city by city, writes each one its own message based on what it already has, and records who has been contacted. Running for sales at Minikauppa.
A·02
The same pipeline, regulated market
In healthcare mobility aids the message is bound by medical device rules and procurement law. A gate went in between the pipeline and the outbox, checking every message before it is even offered for sending.
A·03
Taivutus-API
Inflection comes from rules, the model only writes the example sentence, and gates reject the sentence if the requested form does not appear in it. The API page.
A·04
Fuki
A comic page in, a translated page out. Computer vision finds the speech bubbles, OCR reads them, and the model translates the whole page in one call. All of it runs on your own machine. The app page.
hae Google Places kaupunki kerrallaan
suodata kriteerit 158 loytyi, 114 hylattiin
kirjoita Claude 1 viesti / yritys
tarkasta compliance kielletyt sanat, hinnat, pakolliset merkinnat
merkitse JSON-DB samaan osoitteeseen ei kahdesti
raportoi Telegram joka aamu 09:00The writing step is the only one where the model is genuinely needed. The message is built around what that particular business already has: if a cafe already stocks tea, the message starts from that observation. It is not a template with the name swapped in.
The other five steps use no model at all. The search is an API call, the check is rules, the tracking is a database, the report is a message. Five steps out of six are ordinary integration, which is exactly why the pipeline is cheap to run and predictable.
The checking step is what makes a regulated market possible at all. The gate rejects a message that carries a forbidden health claim, a price, or a missing mandatory marking. Public bodies are blocked outright, because they are to be approached through the procurement channel and not by email. A rejected message never reaches the send queue.
The interesting part here is not what was automated, but what was deliberately left alone:
The default is a dry run. The job writes the messages to a file and sends nothing. Sending is a separate, deliberate command.
Reminders are done by hand. They would be easy to automate, which is exactly why they were not: that is the point where a message stops being outreach and turns into spam.
Volume is capped. A handful of messages a day, not a thousand. A targeted list returns more than a large one, and keeps the sender reputation intact.
The number worth noticing is how many were dropped: more of the businesses found were filtered out than contacted. The filter is the part that creates the value here. A message sent to the wrong recipient costs more than one never sent, and the same holds for automation more generally.
[ 04 ]
How a project runs
01
Scoping
We go through what is done by hand, how often per week and how long it takes. The result is a list ordered by hours saved. Free of charge.
02
Pilot
One process, 1 - 2 weeks, a measurable result. Fixed price and fixed scope, so the decision to continue is made on numbers rather than impressions.
03
Production
Failure paths, logging, alerts and human approval wherever a wrong answer costs money. This stage is what separates a demo from a tool.
04
Maintenance
Models, APIs and prices change. The pipeline gets checked and updated as they do, instead of quietly rotting.
[ 05 ]
How quality is measured
Automation whose accuracy has not been measured is a guess. Before rollout we collect a hand-labelled sample of real data, and every change is run against it. The decision rule is written down before the run, not after.
The same method runs in Taivutus-API, where model output is rejected mechanically if it fails the conditions. An empty response beats a wrong one, and that holds for an invoice and a customer message too.
Stack
[ 06 ]
Common questions
Is our data used to train a model? No. The APIs in use do not train general models on customer data, and if the material is sensitive the pipeline can run on a local model on your own hardware, so the data never leaves the building.
What if the model gets it wrong? That is the starting assumption. Wherever an error costs money or reputation, a human approves before anything moves on. What gets automated is the part where a mistake is cheap and reversible.
What does it cost? Scoping is free, the pilot is fixed scope and fixed price. Production pricing depends on the number of integrations and is quoted only after the pilot has shown what is really needed.
We already have systems, do they need replacing? No. The automation is built on top of the existing systems through their APIs. A rewrite is the last resort, not the first.
Start with the scoping call
Tell me which step eats the most time. We go through it and see whether automating it pays off. If it does not, I will say so.