The conversation about AI in companies often swings between generic enthusiasm and total skepticism. In practice, projects that work best are much more modest: a concrete flow, a measurable bottleneck, and a clear decision about what not to automate yet.
Good candidates to start
- Copying data between tools you already use.
- Classifying or summarizing repetitive inputs (emails, forms, tickets).
- Generating drafts from templates and fixed context.
- Alerting when a metric crosses a threshold you currently check by hand.
What these cases share is predictability. You do not need a model that does everything; you need a flow where error is visible, correctable, and bounded.
What to avoid at first
- Automating high-risk decisions without human oversight.
- Building a generic chatbot before defining what it should actually resolve.
- Integrating five new tools when the problem is one poorly connected workflow.
Applied AI does not replace judgment. It frees judgment from tasks that should not consume senior time.
A sensible first step
Map one real week of a process: what comes in, who touches it, where time is lost. If you can describe that flow on a whiteboard, there is probably a useful first automation. If not, the problem is not technological yet.
How to choose which process to automate first
When several tasks look like candidates, it helps to score them with three simple questions. First: how often does it happen? A weekly task that consumes an hour pays off more than a yearly one that consumes a day. Second: what happens if it is done wrong? The smaller and more visible the damage, the better the candidate. Third: is there a clear input and a recognizable output? If nobody can describe what a good result looks like, there is nothing to automate yet.
- High frequency, low risk and a clear result: start here.
- High frequency, medium risk: automate the preparation and leave the decision to a person.
- Low frequency or high risk: document the process and look at it again later.
An example of a small, useful flow
Imagine a consultancy that receives requests through a web form. Today someone reads them, decides which area they belong to, copies the details into a spreadsheet and messages the person responsible. It is a ten-minute task per request, repeated many times. A well-bounded flow can log each request in the sheet, suggest a classification from the text, notify the right person with a two-line summary and flag for human review the ones that do not clearly fit.
None of this removes people from the process; it removes the mechanical part. And it leaves a visible trail: a sheet where you can check what the tool classified and where it got it wrong, which is exactly the information needed to improve it.
What to have ready before starting
- A process owner, with authority to decide how it should work and to stop it if something fails.
- Real examples, including the hard ones, to test the automation on true cases and not just ideal ones.
- A place to record errors, so they can be learned from and not corrected blindly.
- A simple starting measure — time, volume, errors — to check afterwards whether anything improved.
How to know whether it worked
The result of a useful automation is almost never spectacular: people stop doing a tedious task and nobody mentions it. That is why it pays to set in advance what change you expect and review it after a few weeks: is it quicker, are there fewer errors, is it handled sooner? If no improvement shows, it is better to admit it and adjust or retire the flow than to keep out of inertia a piece nobody uses.
At Ingenia we work on these interventions by connecting existing tools, AI layers where they add value, and an interface when someone needs to supervise or act.