Finance: Is It Worth It?

It is 9:04 on Tuesday morning and Daniel’s mandate is sitting in Omar’s inbox with an exclamation mark in the covering message. Omar has read a few hundred of these: somebody senior has become convinced something is worth doing, and the arithmetic arrives afterwards, if at all.

His job is not to share the enthusiasm, and not to kill the idea. It is to work out whether a dollar spent here comes back as more than a dollar, and to write that down with the assumptions showing, before anybody hires a contractor. By Friday he will have turned an ambition into two numbers still binding in October, long after everyone has forgotten he set them.

What lands on Omar’s desk

Daniel settled the strategic question last week: nobody knows why customers leave, so the $600k goes disproportionately into finding out. His split funded data infrastructure and AI to a combined $325k — not a suggestion but a ceiling. Omar cannot approve an envelope larger than the pots Daniel created, because the money is not there to approve.

With it come the company facts: 400 customers, average contract $24k a year, gross margin 75% — of every $24k of revenue, roughly $18k survives the cost of serving that customer. A new customer costs about $25k to win, and churn has doubled from 9% to 18%.

And one shaky item: an assumption that around 90 accounts are genuinely at risk. The dashboard flags about 120 as quiet, but Hale & Porter LLP goes quiet every August because it is a law firm and everyone is on holiday. Maya sorts the real from the seasonal in module 5, and Omar must price the bet before that happens — which is exactly why he will not quote one confident number.

What a Finance Business Partner actually does

The role is often called FP&A — financial planning and analysis — and a business partner is the version attached to a part of the business rather than to the ledger. Omar is not the person who pays invoices; he is the person who says, before the invoice exists, how big it may be and what it has to buy.

The work has four movements: size the benefit, size the cost including what running the thing takes forever, compare the two over time, then ask how wrong the estimate could be — because the value of a case is not its central number but the honesty of the range around it.

The software on Omar’s desk

Finance’s authority comes from a single idea embedded in its software: there is one official set of numbers, and it lives in the ERP — the enterprise resource planning system, SAP or NetSuite or similar. When Omar quotes revenue, contract values or margin, he is quoting that system rather than a personal spreadsheet, which is why nobody in the meeting can counter with a different figure.

The case itself is built in Excel, and this is worth being unromantic about: behind essentially every funded technology project is a spreadsheet where someone changed an assumption and watched the answer move. Anaplan or a similar planning tool is where that case has to fit into the wider company budget — a project can be worthwhile in isolation and still not fit the year. The output is a slide with two numbers on it, the envelope and the minimum acceptable result, and those two numbers then constrain engineers for the next six months.

The four things Omar decides

Sizing the prize — and counting margin, not revenue

The first decision is what the project is worth if it works — mostly a decision about what not to count.

Ninety accounts genuinely at risk, each paying $24k a year, is $2.16m of annual recurring revenue exposed. That is the headline a hopeful case leads with, and alone it is meaningless, because no intervention saves everybody. Realistic churn programmes rescue between 15% and 30% of those they reach. Omar takes 25% as his expected case: a quarter of ninety is roughly 22 customers, and 22 accounts at $24k is about $540k of revenue kept rather than lost.

Then he does the thing that separates a business case from a sales pitch — he multiplies by the margin, because serving those customers costs something. At 75% margin the real benefit is about $405k a year of gross profit. A third of the headline has evaporated, and it evaporated correctly.

Protected revenue is also counterfactual: you can never point at a customer and prove they would have left, which is why Nadia’s experiment in module 12 exists at all. That cuts Omar’s way too — replacing 22 customers through sales would cost roughly $550k in acquisition costs Northwind now avoids — but he keeps it in a footnote, because a case that stacks every favourable argument into one total is a case nobody trusts.

Costing the thing honestly — including the cost everyone forgets

Against $405k of annual benefit sits the cost, in two halves that behave very differently. The build cost is about $200k: pipelines, model, integration into the tool Customer Success already uses, and the pilot. It happens once. The running cost is about $60k a year — cloud bills, monitoring, retraining the model, and the slice of people’s time this consumes forever. It is the number optimistic cases omit, and omitting it is how organisations end up with forty half-supported systems and no capacity to build anything new.

Now the arithmetic. In a full year the project returns $405k of gross profit and consumes $60k to keep running, leaving about $345k net. Set that against the $200k build and the build repays itself in roughly seven months. Over three years the benefit totals about $1.2m against $380k of cost — an ROI of about 220%. That is the number a weaker analyst would put on the slide in bold, and the number Omar refuses to lead with.

Judging on the downside, not the expected case

The 25% saving rate is borrowed from other companies’ pilots, and rests on a count of 90 at-risk accounts nobody has checked. So Omar runs the model three times.

In the best case the programme saves 30% — 27 customers, about $486k of gross profit a year, the build repaid in under six months. The expected case is the 25% above. In the downside case the saving comes in at half the estimate, 12.5%: eleven customers rescued, about $270k of revenue, $202.5k of gross profit a year. Take off the $60k of running costs and the project throws off $142.5k a year, repaying the $200k build in about 17 months. It is under water through year one, comfortably ahead by the end of year two, and still returns about 60% over three.

That third case decides everything. Projects are rarely stopped for being wrong; they are stopped when confidence runs out — usually in month eight, when the result is ambiguous and somebody senior asks whether this was ever going to work. If the only surviving version is the optimistic one, that conversation is unwinnable, because the honest answer is we needed everything to go right. If the downside still clears zero, the answer is we expected this range and we are inside it, and the funding holds.

So Omar reports all three and judges on the third. A number you would defend in the downside case is worth more than a better number you would have to apologise for.

Setting the two constraints: an envelope and a floor

The output is not an opinion. It is two numbers that bind other people.

The first is the envelope: $250k — the total this project may spend, set deliberately below Daniel’s $325k data-and-AI ceiling and deliberately above the $200k build estimate. The $50k of headroom is not slack, it is realism: Aisha will find in module 7 that Northwind’s data is messier than anyone claimed, and Kofi must choose in module 10 between a simple nightly job and an elegant real-time system costing three times as much. The envelope makes that choice for them before they make it themselves.

The second is the floor: a minimum churn reduction of 12% among the at-risk accounts the programme actually contacts. Omar derives it rather than picking it. Each percentage point is worth about $16k a year of gross profit, so 12% yields roughly 11 saved customers, $194k of gross profit, and — after running costs — payback just inside eighteen months. Below that line the project is not worth its own maintenance. Above it, it earns the right to continue.

Where this goes wrong

Somebody takes the largest defensible benefit, forgets the running cost, quotes revenue instead of margin, produces one triumphant percentage, and gets a yes. The team then spends to the estimate rather than to a cap, because no cap was set. Nobody agreed what success meant, so when the pilot delivers a real but modest improvement it is judged against the optimistic promise and called a failure. The project is not stopped for being wrong; it is stopped for being arguable.

The other failure is upstream and quieter. Had Daniel spread the $600k evenly to keep seven teams calm, the data and AI pots might have come to $120k between them, and Omar would have had nothing viable to approve — not a worse project, no project. A $120k ceiling does not fund a pipeline, a model, an integration and a pilot.

What Omar hands on

What goes to Sofia, the Product Manager, is not a spreadsheet. It is a one-page approval with conditions attached: build whatever you think is right, as long as it fits inside $250k and delivers at least a 12% reduction in churn among the accounts you contact.

That sentence travels the length of the project. The envelope is the cap Aisha designs her pipeline inside in module 7 and Kofi his deployment in module 10 — both billing against the same $250k, neither able to spend it twice. The 12% floor is the bar Nadia’s experiment must clear in module 12; below it, no clever modelling makes this a success, and everyone agreed to that while agreeing was cheap.

Notice what finance approved. Not a model, not a technology, not a team. An outcome, at a price, with the uncertainty written down.

Spot the decision

Read each situation and decide what a finance business partner would say, then tap a card to flip it.