Your First Automation That Is Actually Useful

Where to start: not where everyone else does

This is where the best data is, and it runs straight against intuition.

A study carried out in the first half of 2025 — 52 organisations through structured interviews, 153 executives at four industry conferences, and a review of more than 300 publicly announced initiatives — found that while most of the attention and the money goes to sales and marketing, automating back-office processes can deliver a more dramatic and more sustainable return.

Concrete, measured savings from the same source:

There were results on the front-office side too — 40% faster lead qualification, a 10% improvement in customer retention — but the payback period there was longer and the cost reduction less clear-cut.

(The same report contains the much-quoted claim that 95% of organisations achieve zero return. That figure is disputed in the field, and it has to be read together with the methodology above: interviews and questionnaires collected at conferences, not official corporate reporting.)

So the first evidence-backed piece of advice is: do not start with customer communication, start with an internal, repeating back-office process. That is where the saving is measurable, and where the customer is not the test subject.

Buy it, do not build it

The second piece of advice comes from the same report, and it is backed by a number.

Pilots started with an outside partner or an off-the-shelf platform reached full deployment twice as often as in-house builds: 66% against 33%.

So for a first automation it is worth picking a ready-made platform rather than your own code. Not because your own code is bad — but because the project is twice as likely to finish.

What does it actually cost?

Here comes the number that rearranges most beginners' planning.

Assumption: one run a day (30 a month), one model call per run, 1,500 input and 400 output tokens.

And the platform fee for that same load: between 12 and 20 dollars or euros a month, depending on the plan.

So the platform fee sits somewhere between twenty-three times and a thousand times the model cost. Concretely: with a fast, mid-range model the model costs 11 cents a month and the entry-level platform plan $12 — the platform is more than a hundred times more expensive than the AI itself.

(Own calculation at today's list prices. It excludes retries, failed runs and testing — the last of which is typically the largest item during rollout. And it assumes one run equals one model call: for an agent that can be 3–10 calls, in which case multiply.)

Four consequences:

1. At this scale the choice of model is financially irrelevant. Pick the better one, not the cheaper one.
2. The real decision is the platform. If you have a single automation, a self-hosted, free-licence option is cheaper — but the working hours of running it yourself typically cost more than the twenty dollars you saved.
3. The maths flips once there are many runs. At 3,000 runs a month instead of 30, the model cost is multiplied by a hundred, and from there the choice of model does matter.
4. So for a first automation, do not worry about the model price.

The four things that ruin it

The first: the system does not learn. According to the report quoted above, the main obstacle is neither infrastructure nor expertise, but that most systems do not retain feedback, do not adapt to context, and do not improve over time. The causes, in the report's own words: brittle workflows, missing contextual learning, and a mismatch with day-to-day operations.

The second: what worked once does not work every time. There is a measurement that looks not at whether a task succeeds, but at whether it succeeds eight times out of eight. The best systems of the day scored below 25% on it. The demo where it ran beautifully once says nothing about the eighth run.

The third: the "better safe than sorry" data dump. According to a study across 18 models, output becomes steadily less reliable as the input grows — and even a single item that does not belong already hurts the result. The typical beginner's mistake is to put everything into the prompt. That is not neutral: it makes things worse.

The fourth: the platform limits you run into. These are documented numbers, not surprises:

• On one large platform's entry plan a workflow gets 320 MiB of memory — and the software itself uses an average of 180 of that. According to the documentation, with a complex workflow processing large amounts of data the instance may crash and become unreachable.
• On the same plan, log retention is 7 days or 2,500 runs, whichever fills up first. A month later the log is gone.
• And the documentation honestly adds that at high disk saturation they also delete manually, and that "because of the human steps involved, the alerting system is not perfect".

What should you log?

There is a formal standard for this, so nothing has to be invented. Derived from the observability conventions, eight things without which you will not be able to reconstruct a month later what happened:

1. WHICH PROMPT VERSION ran
   The standard gives it a dedicated field. This is the one
   people miss most when it is not there.

2. WHICH MODEL ANSWERED
   Not the one you asked for — the one that answered.

3. HOW MANY MODEL CALLS AND HOW MANY TOOL CALLS
   This is how you see whether the run ran away.

4. HOW MANY TOKENS went out
   Input, output and cache, separately.

5. WHY IT STOPPED
   Finished, hit a limit, or failed?

6. ON FAILURE, THE CLASS OF THE ERROR
   Not its text. Its class, so that it can be counted.

7. THE IDENTIFIER OF THE CONVERSATION
   Without it the steps cannot be strung together.

8. WHETHER CONTEXT WAS COMPACTED
   If the system trimmed the history in the background,
   that explains the odd behaviour.

And one thing that has to be decided deliberately, not by accident. The standard puts the arguments and the result of a tool call in a separate category: not logged by default, only if you explicitly switch it on — and it notes that they may contain sensitive data.

In plain terms: if you process personal data, the log itself is data processing. That is not a technical decision but a legal one.

The recipe

1. PICK AN INTERNAL, REPEATING TASK
   One that comes up at least five times a week and that no
   customer sees. The measurements put the fastest payback here.

2. WRITE IT DOWN BY HAND BEFORE YOU AUTOMATE IT
   If you cannot write it down, the machine will not manage it.

3. A READY PLATFORM, NOT YOUR OWN CODE
   Twice the chance that you actually finish.

4. FOR ONE WEEK LET IT ONLY SUGGEST, NOT ACT
   Check daily what it would have done. This is the only way
   to find out whether the eighth run is good as well.

5. LOG ACCORDING TO THE EIGHT POINTS
   And check how long your platform keeps it.
   Seven days is not enough.

6. HAVE A STOP BUTTON
   One switch that shuts it down. You should not have to
   look for it when you need it.

The fourth point is the most important one, and it is the one most people skip. A week of "suggest only" mode measures exactly what the demo does not: reliability under repetition.

Common misconceptions

• "Let us start with customer communication, results show up fastest there." The measurements say payback is faster and cost reduction cleaner in back-office processes — yet the money still goes the other way.
• "Let us build it ourselves, we will understand it better." In-house pilots reached full deployment at half the rate of those built on a ready platform.
• "The model will be expensive." With a daily run the model costs a few cents a month. The platform fee is the item that is orders of magnitude larger.
• "It worked in the demo." One-off success and eight-out-of-eight success are two separate metrics, and systems are far weaker on the second.
• "Let us give it as much data as possible." Even a single item that does not belong measurably makes things worse.
• "We will look it up in the log later." If your plan keeps it for seven days, a month later there is nothing left to look up.

What to take away

Three decisions matter for a first automation, and the choice of model is not among them.

The task: internal, repeating, not customer-facing — that is where the benefit is measurable. The platform: a ready-made solution, because you are twice as likely to finish. The proof: one week of "suggest only" mode, because one-off success is not evidence.

And a fourth, which has to be settled along the way rather than afterwards: what you log, and how long you keep it. That determines whether you can say a month from now what happened — and, within GDPR scope, whether you are allowed to at all.

Which platform to pick, and why the billing unit is the heart of the decision, is laid out with prices in the no-code platforms post; the reliability of longer, multi-step runs is the subject of the agent reliability math post, with the arithmetic. And if the system you would automate offers no API at all, the browser and computer-use agents piece tells you when it is still worth starting.