CFO Insights
August 12, 2026

Why Your First AI Project Should Start Where Cash Moves, Not Where Automation Is Easy

Most companies choose their first AI project by asking which workflow would be easiest to automate. It is a reasonable question and it produces the wrong answer almost every time.

The easy workflow is easy precisely because nothing important depends on it. It has few exceptions, few stakeholders, and no revenue attached. Those same properties mean that when the project succeeds, nobody can say what it was worth. The pilot gets described as promising. The budget conversation goes differently than expected. Six months later the tool is still running and no one has built anything on top of it.

The companies that get somewhere with AI in their operations tend to have made a different call at the very beginning. They started close to the money.

What Most Companies Choose for a First AI Project, and Why It Feels Right

Picture a growing manufacturer or distributor. Leadership decides it is time to do something serious with AI. A committee forms. Someone builds a list of candidate workflows and scores them on effort and risk.

The list almost always converges on the same handful of options. Automating internal meeting notes. Summarizing policy documents. Drafting first-pass job descriptions. Cleaning up a marketing content calendar. Every one of these is genuinely useful, genuinely automatable, and genuinely safe.

The logic is sound. You are new at this. You do not want your first attempt to touch a customer, a payment, or a number that ends up in a report. Starting at the edges is how you learn without breaking anything.

The problem is what happens next. The project finishes. It works. And then the executive who has to approve the next phase asks the only question that matters, which is what changed. The honest answer is that some people save some time on something that was never the constraint. That answer does not fund a program.

Meanwhile the actual constraint has not moved an inch.

How to Find the Workflow Where Your Revenue Actually Bottlenecks

There is a faster way to locate the right first project, and it does not require a scoring matrix.

Find the person everyone routes around.

In most growing companies there is a single operator, usually in operations or order management, who holds an entire revenue workflow together personally. Quotes are priced by her because she knows which customers get which treatment. Orders are confirmed by her because she knows which shipments can actually be made. Invoices are built from a spreadsheet she maintains, in a structure that made sense to her four years ago and has been extended ever since.

She is the highest-leverage person in the building and simultaneously the hard ceiling on how much business the company can process. Everyone knows this. It comes up in every leadership meeting as a staffing question, which it is not.

Consider a distributor where the entire quote-to-cash cycle passed through one operations manager. A quote took three days, not because the pricing was hard, but because assembling the inputs meant pulling from four systems and one memory. The sales team learned to stop promising fast turnarounds. Nobody logged that as lost revenue, because it never appeared in a pipeline as a loss. It appeared as a slower company.

That is the workflow. Not because it is the easiest, but because it is the only one where the improvement shows up somewhere a CFO can point at.

Three signals that you have found it:

The work is a chain, not a task. It moves across systems and functions rather than sitting inside one.

Someone is doing manual assembly. Data is being copied out of one place and typed into another, and the copying is where the delay lives.

Real judgment is embedded in it. There are exceptions, and the exceptions are handled by a person with context rather than by a rule.

The Hidden Cost of Piloting AI Far Away From the Money

There is a specific trap in the safe-first-project approach, and it is not that the project fails. It is that the project succeeds in a way that teaches the organization the wrong lesson.

When the first project is disconnected from revenue, the return is invisible, so the case for the second project has to be made on faith rather than evidence. Faith is a much weaker currency in a budget cycle than a number is. The program stalls at exactly the moment it should be compounding.

Worse, the safe project rarely surfaces the hard parts. Workflows at the edge of the business have few exceptions, so they teach you nothing about where human judgment has to sit. The team finishes with confidence they have not earned, and then walks into a revenue workflow assuming it will behave the same way. It will not.

There is also a quieter cost. Every month the constrained operator stays constrained is a month of capacity the company already paid for and did not receive. That cost is real and continuous, and it does not appear on any line item, which is exactly why it gets tolerated for years.

A Four-Part Design for Automating Quote-to-Cash Without Automating the Judgment

Once you have chosen a workflow near the money, the design question becomes precise: what does the system do, and what stays with the person? Four parts, in order.

Gather. The system pulls every input the workflow needs from wherever it lives. Pricing history, customer terms, inventory position, prior orders, open receivables. This is the part that consumes most of the elapsed time today and requires the least judgment. It should be fully automated and it is usually where most of the return comes from.

Draft. The system produces the artifact. The quote, the order confirmation, the invoice. It is complete, it is formatted, and it is explicitly a draft. It shows its inputs, so the reviewer can see what it used and where each number came from rather than being asked to trust a finished-looking document.

Flag. The system identifies what it is not confident about and says so. A customer whose terms changed. A price that falls outside the normal band. An order that will breach a credit limit. This is the highest-value part of the design and the part most often skipped, because it requires deciding in advance what uncertainty looks like.

Decide. A person resolves the flags and approves. Not everything, only the flags. This is the inversion that makes the whole thing work. Today the operator does a hundred percent of the gathering and a hundred percent of the deciding. Afterward she does none of the gathering and all of the deciding, on a shorter list.

The sequencing matters more than the technology. A team that automates drafting without flagging has built something that produces confident, unreviewable output at volume, which is worse than the spreadsheet it replaced.

What a Finance Team Does With the Hours That Gathering Work Used to Take

The reflex assumption is that removing the gathering work reduces headcount. In practice something more interesting happens, and it is the reason this kind of project is worth doing at all.

The operator who used to assemble quotes starts working on why margin is different across customer segments, because for the first time the data to answer that is sitting in front of her in a structured form. The controller who used to chase invoice backup starts working on collections strategy, because the backup is attached automatically. The finance lead who used to spend the first ten days of every month producing the close starts spending them interpreting it.

None of this is a productivity story. It is a scope story. The same people move from producing information to being accountable for what the information means, and that is a genuinely more valuable role for the company and usually a more satisfying one for the person.

The organizations that get this wrong are the ones that treat the freed hours as a cost saving to be banked immediately. They end up with faster reporting and nobody senior enough to interpret it, which is a strictly worse position than they started from.

What Happens to the AI Budget When the First Project Cannot Be Measured

It is worth being concrete about the downside, because it is not dramatic and that is precisely why it goes unnoticed.

Nothing breaks. The safe pilot works. The team is pleased. And then the initiative simply loses altitude. The second project is smaller than the first. The committee meets less often. The champion moves on to something with clearer momentum. Eighteen months later the company is buying point solutions from vendors instead of building capability, because building capability required a mandate that the first project never earned.

Meanwhile the constraint is unchanged. The operations manager is still the bottleneck. The quote still takes three days. The company has spent real money and real attention and has arrived at the same operating ceiling it started at, now with the added belief that AI is somewhat overrated.

The failure was not technical. It was a selection decision made at the very beginning, in a meeting where the criteria were effort and risk instead of proximity to cash.

Three Questions to Ask Before You Approve the Next AI Project

Before the next project gets funded, put it through three questions.

If this works perfectly, what number moves, and who owns that number? If the honest answer is that some people save time, the project is not wrong, but it is not first. Time saved by people who were not the constraint is not a result. Find the workflow where success shows up in cash conversion, sales cycle, or capacity.

Can we describe this process today, step by step, without the person who runs it in the room? If not, that is the real project, and it needs to happen first. Most workflows near the money are undocumented by design, because they were built by a competent person solving problems in real time. Mapping it is not preparation for the work. It is most of the work.

Where exactly does a human still decide, and what triggers the handoff? Any design that cannot answer this precisely will either automate too little to matter or too much to trust. The line has to be drawn deliberately, in advance, and written down.

A company that can answer all three has already done the hardest thinking. The build, more often than not, turns out to be the easy part.

Key Takeaways

  • Choosing a first AI project by ease of automation almost always lands on a workflow nothing important depends on. The result cannot be measured, so the second project has to be funded on faith instead of evidence.
  • The right first project sits where revenue bottlenecks. Find the single operator everyone routes around, usually in operations or order management, who personally holds the quote-to-cash chain together.
  • Three signals you have found the workflow: it is a chain across systems rather than a task inside one, someone is doing manual assembly between systems, and real judgment is embedded in the exceptions.
  • Design it in four parts, in order: gather the inputs automatically, draft the artifact and show its sources, flag what the system is not confident about, and leave the decision to a person. Automating drafting without flagging produces confident, unreviewable output at volume.
  • Freed hours are a scope story, not a headcount story. The people who used to assemble information move to being accountable for what it means, and that is where the compounding return actually lives.