Which process to automate first: how we choose

What we found

A good first process is usually boring, repeated, and already written down somewhere. Almost every first conversation we have starts with the same question. Of everything we do, which piece should go first. This page is how we answer it, and the example is our own work.

Genesco Sports Enterprises is a client of ours. Every month, the finance team rebuilt job-profitability numbers by hand from Sage 50 exports. We built software that does the mechanical part of that close. A month-end reconciliation that took the CFO about 4 days by hand now runs in about 60 seconds.

Those figures belong to Genesco and they are public with their permission. They describe one company and one process. Your work will have its own shape, and these numbers are not a prediction about it. What travels between companies is the way we picked the process, so that is what the rest of this page covers.

What a first process needs

We look for clear inputs, clear outputs, real manual effort, and rules a person can write down.

• Clear inputs and outputs. You can point at what comes in and what goes out. A file, a form, a report, a finished workbook.
• Manual effort you can count. Hours a week or days a month, done by a person who is paid for a different skill.
• Rules that can be written down. If someone can describe every step and every test for a good result, software can own those steps.
• A decision point that stays with a person. Most work has a place where someone weighs something nobody ever wrote down. That part stays human, and knowing where it sits tells you where the build stops.
• Room to be wrong. A first build needs a process where a mistake is caught and fixed the same day. Work with zero tolerance for error is a poor place to learn.
• Data you can actually get at. An export, a database, an inbox. Scattered data is workable. No usable source is not.

A process does not have to meet every one of those. We are looking for one that meets several, and for a build where being wrong once is survivable.

The three questions we ask first

We ask three questions about a process before we score it.

• What starts this work, and what does it produce?
• What are the steps, in the order they really happen?
• Who does each step, using which data and which systems?

The first question brackets the process. The second fills the middle. The third says what each step runs on and where the know-how lives. A description with steps but no trigger is a list of tasks. A description with no roles cannot be scored, because you cannot see which steps depend on one person's head.

The mapping is finished when the person doing it can say one sentence honestly. I understand how this work runs today and what it produces. Until then, the next question is whichever of the three has no plain answer yet.

The mapping turns a general complaint about a slow month into named steps with hours attached. Our guide to doing it yourself is how to run your first AI audit in an afternoon.

The Genesco reconciliation, scored

Genesco's month-end close met the tests before we wrote any code.

The inputs were clear. They were Sage 50 exports, produced the same way every month. The output was clear too, a reconciled master the finance team could stand behind.

The manual effort was large and countable. The reconciliation took the CFO about 4 days by hand, every month, forever. That is a finance leader spending days on importing, reconciling totals across spreadsheets, and re-keying prior-month profit figures.

The rules could be written down. Sums, job totals and carry-forwards all follow a stated rule, so software can do them. The figures that depend on context, on a conversation, or on a call about how a job should be treated follow no written rule, so the finance team kept them.

The decision point was easy to find and easy to keep. The build hands back a clean workbook for the judgment calls, and the reviewed workbook goes back in. Someone uploads, reviews and downloads, so a person sees the numbers before anything is final.

The risk was manageable. The close runs once a month, a person reviews every output, and each run leaves a record of what went in and what came out. If a figure looked wrong in the first month, there was a whole month to fix it before the next one.

Our write-up of that build covers what the software does and what it left alone.

Mark Tatum, Genesco's CFO, described the result this way: "Every month our team burned hours rebuilding job-profitability numbers from Sage by hand. Plainpath built us a tool that does the heavy lifting and leaves us just the judgment calls. It has saved us real time and headaches, and they were quick to adjust it when we asked."

Weak first candidates

A process is a weak first candidate when nobody can say what good looks like.

Here are the ones we steer people away from at the start.

• Work with no named outcome. If the answer to what changes for you is vague, there is nothing to measure at the end and no way to tell whether the build worked.
• Work where judgment enters at every step. There is no mechanical part to hand over, so the build turns into a long argument about rules that were never agreed.
• Work with no usable data source. If the information lives only in people's heads and in phone calls, the first project is getting it written down.
• Work with zero tolerance for error and no human check. Safety, payroll into bank accounts, anything regulated with no review step. These are buildable later, with real guardrails. They are a bad place to learn.
• Work that is already fully automated by ordinary software. If a rule in an existing tool does the job, use the rule.
• A whole department at once. Parallel builds across a department leave you with half-finished work and no proof. One workflow, running live, with a number attached, is what earns the next one.

We say so plainly when we see one, and the conversation moves to the process sitting next to it.

We wrote about what happens when a build has no owner and no payback date in why most AI pilots fail.

The plain take

Start with work that is repeated, countable, written down somewhere, and safe to get wrong once. Map it before you score it, using the three questions, and mark the point where a person makes a call that no rule describes. That point is where the build stops and the reviewer starts. If you want a person to check your map and write a build plan against it, that is Discovery. If you want a starting point that costs nothing, our audit is free and you can run it yourself.

Frequently asked questions

Which process should we automate first?

Pick one with clear inputs and outputs, real manual effort you can count in hours or days, rules a person can write down, and a decision point that stays with a person. It also helps if being wrong once is survivable, so you have room to learn. A process does not need all of those, but the more it has, the better a first candidate it is.

How do we know a process is too risky to start with?

If an error would do real harm before anyone could catch it, and there is no human review step in the flow, it is a poor first build. Work like that can be built later with proper guardrails. Starting there means learning on the thing you can least afford to get wrong.

What did Plainpath build for Genesco Sports Enterprises?

Every month, the finance team rebuilt job-profitability numbers by hand from Sage 50 exports. We built software that ingests the exports, computes the job totals and pre-fills the figures the rules allow, then hands back a clean workbook for the judgment calls. A month-end reconciliation that took the CFO about 4 days by hand now runs in about 60 seconds.

Do we have to map the process before we talk to you?

No. Bring what you have. A rough answer to the three questions is enough to start a conversation, and our free audit walks you through the same ground. Discovery is where a person checks that map, digs into your top three processes, and writes the build plan.

Can we start with several processes at once?

We advise against it. Running several builds at once leaves you with half-finished work and no proof. One workflow, live, with a measured before and after, is what makes the case for the next one.

The plain take

Genesco's month-end close repeated, the effort could be counted, the rules could be written down, and a bad figure would have been caught inside the same month. That is why it went first. If you want to try the same test on your own work, our audit is free, and Discovery is where a person checks your map and writes the build plan against it.