Internal tool business case

Direct answer

The business case for an internal tool is the cost of the workaround you use now, set against the cost of building and running a proper tool. The workaround is usually a set of spreadsheets, shared inboxes and someone who knows how it all fits. It has real costs in time, errors, risk and dependence on individuals. Price those from your own observations, add a realistic build and run cost, and compare. This page publishes no savings figures because yours will differ.

It is a framework, not a calculator. For what drives the cost of building the tool, see internal business tools cost, and to decide the form the tool should take, see low-code versus custom internal tool. The wider service is described on the internal business tools page.

Workaround costs

Begin with what the current way of working costs in time. Ask the people involved to record, for a couple of typical weeks, what they do in the workaround: copying data between files, chasing status by message, rebuilding a report, fixing an entry someone else made. Record time by task, not a single total, so you can see which parts a tool would change.

In symbols: tasks per week x minutes per task x internal cost per hour. Keep the internal rate to whatever your finance team accepts, and keep the calculation visible so a sceptical reader can change an input and see the effect.

• Time on repeated copying, reconciling and reformatting.
• Time spent finding the current version of a file or the status of a job.
• Time correcting errors and re-checking work.
• Time spent explaining the process to new or covering staff.

Users and tasks

Count who would use the tool and what each group would do in it. A tool for two specialists who do everything differs from a tool for thirty people doing one repeated task. List the roles, the tasks per role, how often each is done and what data each needs to see or change. This becomes both the basis of the cost calculation and the first draft of the scope.

Note what users do not need. Many internal tool cases weaken because they try to replace everything at once. A narrow first version covering the most repeated task is easier to justify and easier to measure.

Risk

Workarounds carry risks that do not show up as time. A spreadsheet held by one person, a formula nobody understands, data with no history of who changed what, and access that cannot be limited are all exposures. Describe each in plain terms: what could go wrong, what it would cost you if it did, and how you would notice.

Resist attaching precise probabilities. A short list of named risks with a qualitative severity is credible and lets the approver judge. Where a failure would cause a cost you can measure, such as a missed delivery or a mis-billed client, treat it in the same way as the error costs above.

Build versus keep

Compare at least three options: keep the current workaround, improve it in place, and build a tool. Improving in place, for example tidying the spreadsheet, adding validation or a shared template, may capture part of the benefit at low cost, and a fair case shows it. A tool is justified where the workaround cannot be improved enough, such as when several people need controlled access to the same data or when the process needs its own rules and history.

Put the options in one table using the same headings: one-off cost, running cost, error cost, risk and effort to change later. If the tool wins only under optimistic assumptions, say so, and consider the smaller build.

Run cost

A tool is not finished on delivery. Include hosting, any subscriptions, the time to fix problems and to change the tool as the process changes, and someone's responsibility for it. Ask for the written scope to state what is included in the build and what is handed over, including code, accounts and documentation in your name, so that you can judge the long-term position.

Compare this ongoing cost with the ongoing cost of the workaround, not only the build with the workaround's current monthly cost. A fair comparison uses the same period on both sides.

Measures

Decide before you build which measures will tell you whether the tool worked. Choose a few that follow directly from the workaround costs: time per task, number of corrections, time to produce a standard report, number of times someone had to ask for status. Record the baseline now, since it cannot be reconstructed afterwards.

Set a date to check the measures after launch and name who will do it. A case that includes its own review is more persuasive and gives you honest evidence for the next request.

How to pitch approval

Approvers want a short, checkable argument. Lead with the problem in operational terms, show the measured workaround cost with its inputs, present the options side by side, and state the smallest build that would test the case. Include the risks and what you would do about them, and what you will measure afterwards.

Avoid bringing in claimed savings from other companies or vendors. They invite the question of whether they apply to you, and your own measured numbers answer it better. Offer a small first scope with a defined review point, since it lowers the cost of saying yes.

Limits of the estimate

Be explicit about what the estimate cannot tell you. Observed time is a sample, not a forecast. Process changes during the build will alter the tasks. Some benefits, such as fewer interruptions or better visibility, are real but hard to price, and should stay listed and unpriced. Show a pessimistic version of the calculation and note which input it depends on most.

If you would like the case reviewed against a written scope, the internal business tools page explains how we scope one tool with a single scope and price agreed before work starts, and we will say plainly if a smaller fix would serve you better.