A finance team told me recently that they’re not hiring anyone for now. They first want to know if AI can absorb the growth. What I liked about it is that they’re betting their own workload on it. If AI doesn’t deliver, they’re the first to feel it.

And for once the alternative has a price tag. If it doesn’t work, they hire someone, and they know exactly what that costs.

The problem with hours saved

Most business cases I see are built on hours saved. Someone is an hour faster per week with Copilot, times the hourly rate, times the number of licences. The problem is that nobody knows how long that task would have taken without Copilot. And a saved hour often just disappears into the rest of your week.

That is the part finance never gets comfortable with. The number is real on the slide, and nothing in the cost base moves afterwards. You end up defending a figure that nobody can trace back to a line in the budget.

Why a hiring freeze is a fairer test

With a hiring freeze, that works differently. The work keeps growing anyway. Either the team absorbs it, or you still need that extra colleague. You can simply see the outcome.

The test also has a date attached to it. A vacancy either opens or it does not, and everyone can see which one happened. You are not asking anyone to estimate something.

Most of the work is just rules

Where that room has to come from is less exciting than you might think. In our sessions with this team, we talked about:

• the monthly timesheet check

• the fixed checks during month-end close

• getting numbers from Excel into the monthly report without copy-pasting

• letters that now take around twenty minutes each

Most of that is just rules. You often don’t need a language model for it. A small script that runs the same checks every month does it better.

It is worth being honest about that early, because it changes who needs to build it and what it costs to run. A rules-based check does the same thing every month and you can test it once. A language model needs someone watching the output.

The capacity catch

That’s also where it gets difficult. At the end of the session, the team said capacity is their biggest issue in the short term. The people who have to automate the work are the same people now absorbing the extra work.

The tool for building it themselves was already switched on, and finance hadn’t done anything with it yet. I get that, because almost nobody manages that next to their normal job.

So a hiring freeze without someone building alongside the team mostly becomes a team that has to work harder.

If you run this test, give the team someone who builds. That can be a person from inside the company or someone you bring in for a few months. Without that, you are measuring how long people can keep going, which is a different question.

Run the old and the new process side by side

If you want to know whether it works, run the old and the new process side by side for a while until the outcomes match. After that, you look at whether the same team can handle more volume.

Running both costs extra effort for a while, and that is the point of it. You find the cases where the new process gives a different answer, and you fix those before anyone depends on it. Set an end date for the comparison so it does not run forever.

Say out loud what the goal is

And as management, say out loud what the goal is. Nobody is being replaced, this is about the next vacancy. People who are afraid for their job will otherwise start resisting in small ways.

That resistance is hard to see in a report. Work gets routed around the new process, or the old spreadsheet stays open next to it. Saying the goal out loud early costs you nothing and removes most of it.

I’m curious whether your AI business case would pass this test.

Originally posted on LinkedIn