The Workday Extend business case in one page

A finance director told us last year that she reads about 40 IT business cases a quarter. Maybe 8 of them stick in her head long enough to get a follow-up question. The rest blur together. If your Extend case looks like the other 32, the technology will not save you.

This is the version we coach HRIS leaders to write. One page. Four numbers. Three approvers. One sentence on why it has to happen now.

The problem, with a number and a name

Most cases open with something like "contractor onboarding is slow". That sentence buys you nothing. It could describe any company in any industry.

Try this instead. "Contractor onboarding takes 18 working days. We onboard around 60 contractors a quarter. The delay costs us roughly two days of contractor productivity per hire. Maria's team in HR Ops spends about 90 minutes per case chasing data across three tools."

That paragraph has a number, a name, and a process. It tells the reader what is actually broken and who feels it. If you cannot write a paragraph like that, your case is not ready and no amount of formatting will save it. Spend an afternoon with the team doing the work. Time the steps. Come back.

Prove you need to build, not buy

Approvers want to see that you considered the alternative. If a Built on Workday app already covers the need, buy it and move on. Extend is for problems the marketplace cannot solve, or for capability you want to build over several use cases.

A short paragraph in your case showing the two or three Built on Workday apps you looked at, and the reason none of them fit, does more work than people realise. It tells the CFO that you did not jump straight to "we want to build something". It tells IT that you respect the platform. It tells the operating team that you are not in love with the technology.

Four numbers. No more

Most business cases drown in spreadsheets. The one-page version has four numbers, and finance can find all of them in under ten seconds.

Annual benefit. Hours saved times loaded rate, plus any external tool you are retiring. If you are claiming risk reduction or revenue impact, attach a probability to it. "70 percent chance we avoid a 50,000 euro fine" is honest. "Improves compliance" is not a number.

Annual cost. Five lines: Extend license, build (internal or partner), training, ongoing support, contingency at 10 to 15 percent. The line teams forget is ongoing support. Finance always notices.

ROI. Annual benefit divided by annual cost. If it is under 1.5 in year one, work the numbers harder or pick a stronger use case. A weak first case poisons the well for the next three.

Payback period. Months until the cumulative benefit covers the cumulative cost. If you cannot break even inside two years, the case is fragile, and the first cost overrun will kill it.

A worked example

Anonymised from a real client. The app replaced a contractor onboarding process that ran on three tools and a shared Google Sheet. Build effort was about 9 weeks with a partner. Annual benefit: 520 hours saved at a loaded rate of 50 euro, plus 18,000 euro of retired tooling, total 44,000 euro. Annual cost: 35,000 euro in year one (build plus first-year support), 12,000 euro in year two onwards. ROI in year two: 3.6 times. Payback: 11 months.

Workday's own claim is that Extend apps take roughly 75 percent less effort than equivalent custom builds. That number is theirs, not ours, and you should treat it as a directional statement rather than something to put in a financial model. The number that matters in your case is the build estimate from whoever is actually going to build it.

Stop loading the case with intangibles

We used to recommend a strong intangibles section: agility, audit readiness, employee experience, strategic alignment. Finance teams kept tuning it out. The phrase "strategic alignment" reads to a CFO the same way "synergies" reads to anyone else, which is to say, like filler.

Keep at most two intangibles. Pick the ones connected to a real conversation already happening in your business. "Auditors flagged our manual contractor process in last year's report" is a real intangible. "Supports our digital transformation journey" is not.

Brief three people, then write three sentences

Before you ever circulate the case, talk to the three approvers separately. Ask for feedback, not approval. By the time the steering committee meets, the case is half-approved and the difficult questions are already answered. This is the part that decides whether your case lands this quarter or slips into next budget cycle, and it has nothing to do with the technology.

Then write one sentence per approver, on the page. For the CFO: ROI, payback, and the line about ongoing support you remembered to include. For IT: that the app runs on Workday's security model, with no new infrastructure, no separate integration platform, no extra logins. For the HR or finance ops lead whose team will use it: what changes on day one for the user, in their language, with no acronyms.

The "why now" line is the line you must not skip

"Why now" is the line that decides whether your case gets approved this quarter or parked for the next budget round. It should sound like one of these. A vendor contract is up for renewal in 90 days. A compliance deadline is closing. The Workday release this autumn ships a feature that unlocks the app. A peer in the industry just launched something similar and your CEO has noticed.

If you cannot finish the sentence "if we do not start in the next quarter, then...", the urgency is not there. That is useful information. Park the case and come back when the answer is real. Cases that get approved out of polite interest tend to lose their sponsor before go-live.

The layout

Top half of the page: problem in two sentences, proposed Extend app in two sentences, four numbers in a small table. Bottom half: stakeholder one-liners, the why-now line, the recommendation in a single sentence. Something like "Approve a 75,000 euro investment to build the contractor onboarding app, delivering 44,000 euro of annual benefit, with our delivery partner over 10 weeks." If it does not fit on one page, you are not ready to send it.

Keep the spillover material as an appendix. Approvers rarely read it. Auditors sometimes do.

Read it back as the CFO

The test we use before we send: read the page back out loud, in the voice of the CFO who is sceptical of every IT request that crosses her desk. If the case still sounds confident at the end of that read, it is ready. If you find yourself adding caveats in your head as you read, the case needs another pass.