Automating a repetitive task without breaking anything

The starting point is not the technology

According to the Barometre France Num 2024, 13 % of French small and medium businesses report using artificial intelligence. The figure is usually quoted as a gap to close. It says something else above all: most owners have not found the first use that is worth the effort.

The real subject is not the tool. It is the choice of the task to automate first, and that choice alone. A company can have access to the best models on the market and still fail the project completely if those models are applied to the wrong task. Conversely, a modest automation placed on the right task changes a team's daily work immediately. Before discussing architecture or vendor, the question to answer is simple: which task, exactly, deserves to be handed to a machine?

The two axes that point to the right task

A task deserves to be automated when it is frequent and its error is recoverable. These are the only two questions to ask, in that order. Frequency justifies the design effort; whether the error is recoverable sets the level of control to put in place. Cross the two axes and you get four cases, which in practice cover almost every situation a small company runs into.

Frequent and recoverable: the top priority

This is your first automation, the one to start with. Sorting incoming requests, preparing a summary, answering the question asked forty times a day: these are tasks that keep coming back, and an occasional error in them can be fixed in a few seconds with a message or a follow up call. The ratio between the effort of building it and the gain obtained is at its best here. It is also the easiest task to observe: it leaves a visible trail, a measurable volume, and a team that already knows exactly what a good answer looks like.

Rare and recoverable: leave it aside

Drop it. The design time will exceed the time saved, and the automation will stay underused, with the risk of becoming a system that gets maintained without ever really being exploited. A rare task almost never justifies the scoping, testing and monitoring effort that a clean automation requires. It is better to keep that time for the next task, the one that comes back every day.

Frequent and costly when wrong: automatable, under control

This case is automatable, but only with a check carried out by the system itself, never left to the sole output of a language model. This is typically the case for a price or an availability: frequency pushes toward automation, but a mistake can be costly, in money or in customer trust. Good practice is to separate the generation of the answer from the calculation of the sensitive figure: the text can be produced freely, but the number shown must come from a verified source and be recalculated every time, never written from memory.

Rare and costly when wrong: keep a human

Keep a human. A hiring decision, a contract termination, an exceptional commercial gesture have nothing to gain from being sped up. These are situations where the rarity of the event makes automation poor value, and where the cost of a mistake, often human as much as financial, largely exceeds any possible time saving. This is also where a well thought out automation is distinguished from a badly scoped project: knowing when to say no to a task matters as much as knowing how to automate another one.

The missing reflex

Always ask what happens when the automation gets it wrong, before asking how much time it saves. The two answers do not carry the same weight: saving ten minutes does not make up for a wrong invoice sent to two hundred customers. Asking this question first often changes the final decision, and avoids discovering the real cost of a mistake after going live rather than before.

Reduce before extending

The natural reflex, once the first automation is in place, is to add cases to it. That is almost always a mistake. On our own platform for managing teams on the road, presented in our projects, the useful redesign added nothing: it brought twenty three navigation entries down to six, merged three dashboards into one, and cut the creation assistant to three steps.

The time saved did not come from an extra feature. It came from removing everything that forced a choice. Every extra screen, every secondary option shown permanently, every step that could be guessed by the system instead of asked of the user, slows the whole thing down. Reducing is not giving something up: it is often the move that produces the most gain for the least effort, and it usually costs less than adding a new feature. This is easy to forget once a project is under way, because adding something new feels like progress while removing something feels like a step backward, even when the opposite is true in practice.

What we remove first

• The screens nobody opens. They cost their maintenance and blur the navigation for the ones that remain, while giving the impression of a tool more complex than it needs to be.
• The form fields filled in just in case. A thirteen field form is filled in badly; the same form with four fields, advanced options folded away, is genuinely filled in, and quickly.
• Duplicate concepts. Two schedules, two notions of a customer, two places for the same invoice: every duplicate is paid for in training and in data entry errors, and almost always ends up drifting apart over time.

Mistakes that break an automation

Some mistakes come back from one project to the next, whatever the sector, the size of the team, or the kind of task targeted. They are not specific to a particular trade: the same patterns show up in a consulting firm, a production workshop, or a local shop. Knowing them before starting avoids repeating them, and often saves several weeks of pointless scoping.

• Automating a task because it is technically interesting, not because it is frequent. That is the surest way to build a sophisticated tool nobody uses.
• Letting the language model generate a piece of data that should be calculated by the system: a price, an availability date, a total. The text can be free, the figure must be verified.
• Launching the automation without having defined what happens in case of an error. The failure scenario must be thought through before the success scenario, not after.
• Stacking features on a first version that already works, instead of simplifying it. Every addition should be justified by an observed real use, not by an appealing idea.
• Neglecting the training of the people who will use the automation every day. A simple tool that is poorly explained stays underused, exactly like a complex one.

Questions to ask before launching

Before any automation project, a few questions help decide quickly whether the target task is the right one:

• Does this task come back every day, or only from time to time?
• If the automation gets it wrong, does the error get fixed in a few minutes, or does it take weeks to repair the consequences?
• Does a sensitive piece of data, such as a price or an availability, need to be generated, or can it be calculated by the system and simply formatted?
• Who, in the team, will use this tool every day, and were they involved in its design?
• What is removed from the existing setup by putting this automation in place, rather than what is added to it?

This kind of scoping is usually done upfront, during an assessment: it identifies the most valuable task before any development is committed, and avoids investing in a project that would never pass the test of the two axes described above. This scoping rarely takes more than a few days, while a badly targeted project can occupy a team for months without ever producing the expected gain.

In practice, these questions are usually discussed in a meeting with the people who carry out the task every day, rather than with management alone. They are the ones who know exactly where the real friction sits, which steps are redundant, and at what point an error becomes hard to fix. Ignoring this level of detail often leads to automating an idealised version of the task, one that does not match what actually happens on the ground.

Measure before optimising

An automation consumes: design time, maintenance, and energy at every run. The RGESN and AFNOR Spec 2314 set out the same discipline as the one described above, from another angle: build only what is necessary, and know how to drop a project whose cost exceeds its use. This logic of restraint connects directly to our approach to responsible AI: an automation is only progress if its balance sheet, once measured, stays positive.

That is also why we measure what our deployments consume, with the Kabaun platform. An automation that saves an hour a week and costs more in infrastructure than it saves in wages is not progress. Measuring is not an optional step reserved for large projects: it should accompany even the smallest automation, to check regularly that the initial calculation still holds over time.

To go further on the methods we apply, the automation page details how we scope, reduce and measure a project, and the use cases page presents other concrete examples. If your team is still hesitant about which task to choose first, an engagement can settle it quickly, without launching an oversized project from the start.

Sources

• Conversational agents and virtual assistants, France Num guide (Ministry of the Economy)

Frequently asked questions

Which task should a small business automate first?

One that is both frequent and whose error is recoverable: sorting incoming requests, preparing summaries, answering repetitive questions. The frequency justifies the effort, the recoverable nature limits the risk.

Which tasks should not be automated?

The ones that are rare and whose error is costly: a hiring decision, a contract termination, an exceptional commercial gesture. The time saved is small and the risk is high.

Should features be added as you go?

Rarely. On our own products, the clearest gains came from removal: fewer screens, fewer fields, fewer duplicate concepts. It is better to narrow the scope before extending it.

How many French small and medium businesses use AI?

13 % according to the Barometre France Num 2024, while a majority of owners consider AI important in the medium term. The gap owes less to the tools than to the absence of a clearly identified first use case.