Choosing Your First Automation

Start with a decision, not a tool

The best first automation is rarely the most technically impressive process in the business. It is the one where a clear operational problem can be stated in plain language: a team spends too much time compiling a recurring report, routing routine requests, checking whether required information is present, or moving data between established systems. If the problem cannot be described without referring to a particular AI product or automation platform, pause before selecting technology.

Set an explicit business objective before assessing feasibility. The objective should name the intended change and the person or team it affects. For example: reduce the manual effort needed to prepare a weekly internal status summary while preserving the manager’s final review. This is more useful than a broad ambition to “use AI,” because it gives the project a boundary and makes later measurement possible.

Executives and business teams should also distinguish between a process that is annoying and a process that is consequential. Repetition alone does not make a process a strong first candidate. A useful candidate has a visible connection to time, consistency, responsiveness, risk reduction or decision quality, and that connection can be checked after deployment.

• Can the process be described as a repeatable sequence of inputs, decisions and outputs?
• Is there one business objective that the team can state in a sentence?
• Would a change in the process matter to a defined group of users or stakeholders?

Look for stable, bounded work

A realistic first automation usually handles a bounded part of a workflow rather than attempting to replace an entire department’s judgment. Good boundaries can be a particular request type, a recurring document format, a defined handoff between two systems, or a specific stage before a human decision. The narrower scope makes it easier to see what the automation is expected to do and what remains outside its responsibility.

Stability matters because automations depend on reasonably consistent rules, inputs and outcomes. A process can still include variation, but the team should understand where variation occurs. If every request arrives in a different format, relies on unwritten exceptions and ends in a different kind of decision, the first project may need process clarification or data preparation before automation is appropriate.

The question is not whether people should be removed from the workflow. In many useful first projects, people retain the decisions that require context, accountability or interpretation. Automation can prepare, sort, extract, draft or flag work so that human attention is concentrated where it is most needed.

• Prefer a process with a clear start and finish.
• Identify known exceptions before building around the standard path.
• Define which step requires human review and who performs it.

Assess data control and safeguards

A candidate process is only realistic when the data needed to run it is controlled well enough for the intended use. That means the team can identify where inputs come from, who is allowed to access them, how current they are and whether their quality is sufficient for the proposed task. A useful automation cannot compensate reliably for unclear ownership, inaccessible information or inconsistent source material.

Controlled data does not mean that every record must be perfect. It means the project scope acknowledges limitations and uses safeguards that fit the process. For instance, a workflow may reject incomplete submissions, identify uncertain fields for review, limit access to approved users or retain the original material alongside an automated draft. These choices make it easier to trace what happened when a result needs to be checked.

Consider the consequences of an incorrect result before deciding how much automation to use. Low-consequence preparation tasks may support a lighter review pattern than outputs that affect customers, finances, sensitive information or important internal decisions. Human review should be explicit: identify what is reviewed, when it is reviewed and what the reviewer can correct or stop.

• Map the approved source data and its owner.
• List the access controls and handling rules relevant to the workflow.
• Design a path for incomplete, conflicting or uncertain inputs.
• Keep a human review point proportionate to the consequence of error.

Example: comparing two candidates

Example decision aid: imagine a business team is choosing between automating weekly project-status summaries and automating approval of all incoming supplier requests. The status-summary workflow gathers updates from known internal systems, produces a standard format and is reviewed by a manager before distribution. The supplier-request workflow may involve varied documents, exceptions, approvals and decisions with broader operational consequences.

The first candidate has a clearer initial boundary: collect approved inputs, prepare a draft against a fixed structure and present it for manager review. Its objective might be to reduce manual preparation effort while keeping the manager accountable for the final summary. Its production measurement could include the proportion of summaries prepared through the workflow, the time required for preparation and the number of corrections made during review.

The second candidate may eventually be valuable, but it is less suitable as a first automation if its rules, data sources and escalation paths are not yet defined. A team could begin by automating one lower-risk substep instead, such as confirming that a request includes required fields or routing complete requests to the appropriate reviewer. That narrower project can expose data and process issues without assuming that end-to-end approval is ready for automation.

Use this simple comparison for each proposed process: score its objective clarity, input control, rule stability, consequence of error, human-review design and measurement plan as clear, partial or unclear. A process with several “unclear” ratings is not necessarily a bad idea; it is a signal that preparation is needed before it becomes a realistic first project.

• Objective clarity: Can the intended business change be stated plainly?
• Input control: Are the relevant data sources known, authorized and usable?
• Human review: Is there a named person or role to validate important outputs?
• Production measurement: Can the team observe use, corrections and the intended outcome?

Plan measurement before deployment

Production measurement is not a reporting exercise to add after launch. It is how a team learns whether the automation is being used as intended and whether it supports the explicit business objective. Decide in advance what will be observed, who will review it and what would indicate that the workflow needs adjustment, a narrower scope or additional safeguards.

Measures should fit the process rather than imitate a generic dashboard. For a drafting workflow, relevant observations may include how often people use the draft, how often reviewers make material corrections and whether the preparation step takes less manual effort. For a routing workflow, the team may observe whether requests reach the right queue, how many require re-routing and where exceptions concentrate. These observations should be interpreted alongside context, not treated as automatic proof of value.

Set a follow-up point after deployment. Review the workflow with the people responsible for using and maintaining it, compare the observed behavior with the original objective and decide what to change. This keeps the project connected to practical operations instead of treating deployment as the end of the work.

• Write down the baseline process and the intended change.
• Track adoption, exceptions and reviewer corrections in production.
• Schedule a follow-up review with clear ownership for improvements.

How this guidance fits Victor Laybats’ context

Victor Laybats provides AI and automation engineering services from Paris. The public context describes an approach that runs from scoping through deployment and follow-up. This article is practical guidance for evaluating a first candidate within that kind of lifecycle; it is not a claim that one template, tool or process will fit every organisation.

The recommendations are deliberately bounded. A useful AI project depends on controlled data, appropriate safeguards and an explicit business objective, while outcomes depend on context, existing systems and input quality. For that reason, a candidate that looks promising on a checklist still needs scoping against the organisation’s actual workflow, data environment, review responsibilities and operating constraints.

For business teams, the useful conclusion is straightforward: choose a process that is narrow enough to understand, important enough to justify attention, safe enough to review and measurable enough to improve. That creates a sound basis for deciding whether to proceed from initial scoping toward deployment and follow-up.

• Do not treat a checklist as a substitute for process and data scoping.
• Keep safeguards and human review aligned with the workflow’s consequences.
• Expect the production design to reflect existing systems and input quality.