Guide

Choosing your first business process for AI implementation

The first process sets expectations for everything that follows. Choose one that is too ambitious and the project turns into a debate about AI. Choose one that is too small and nobody notices that it worked. These criteria come from mapping work with municipal, utility and commercial teams.

Signs of a good first process

• It happens often. A weekly report, a recurring cycle of account checks, applications that arrive every day. Repetition gives you a baseline and enough cases to test against.
• Most of the effort goes on checking, not deciding. In one utility mapping, most of a team’s billing cycle went on exporting reports to spreadsheets and reviewing accounts one by one, although only some accounts needed judgement. That kind of work can be sorted into three groups: closed, needs a defined action, needs a person.
• The rules can be written down. Thresholds, required documents, validity tables. If the rules exist only in one person’s head, the first task is to write them down, not to automate them.
• Someone owns it. A person with the authority to approve the rules and to say what counts as a correct result.
• The data can be reached. The files, boards and systems the process depends on can be accessed with permission, ideally through an interface.
• Success can be measured. Preparation time, the number of exceptions caught, or the time between an event and the action that should follow it.

Warning signs

• The process depends on a system that nobody is allowed to connect to.
• Errors carry high regulatory or financial exposure, and there is no willingness to run a shadow period first.
• Departments disagree about how the process should work. Settle that before building anything.
• The stated goal is to cut headcount rather than move people’s time to the cases that need them. That framing usually stops the people who know the process from helping.

A simple way to compare candidates

Place each candidate on two axes, contribution and complexity, judged against the systems you have today. For each one, note whether it should be built, bought, or handled by adopting a tool you already own under a clear procedure. Start where contribution is high and complexity is low, and write down why the others were left out so the decision can be revisited.

Keep the first scope narrow

In a municipal permit project, the workflow starts with a single eligibility route, and exceptions and other intake channels stay with employees. In a large enterprise, mapping several departments surfaced many opportunities, and we started with the ones that promised the quickest wins. A narrow first scope is easier to test and accept, and it shows quickly where the rules are unclear.

Agree how it will be accepted

Before building, agree the baseline and the acceptance conditions with the process owner: what will be measured, on which sample, and what result counts as good enough. Without that, the end of the project becomes a matter of opinion.

Limits

These criteria help you decide where to start. They do not tell you in advance how much time you will save. Figures produced during planning are working assumptions; the pilot measures the baseline and the actual result.