When to Replace Spreadsheets with a Custom Internal Tool

Spreadsheets are useful for calculations, exploration, and changing a process quickly. Having several users does not automatically make a spreadsheet unsuitable. The problem appears when people cannot complete the work reliably within the current setup.

An internal tool is software used by your own team to carry out a business task. It might manage requests, stock checks, scheduling, or approvals. It does not need to replace every spreadsheet in the business.

Find the actual problem before replacing the file

Review a recent task from start to finish. Look for repeated data entry, unclear status, missing records, and corrections after a handoff.

Ask the people who use the file what would make their work easier. They may need a simpler form, stronger validation, or a shared record identifier rather than a new application.

The discovery principle is to understand the problem and consider alternatives before committing to a build. A process improvement can be a valid outcome. GOV.UK discovery guidance

Compare three routes

Route	Good reason to choose it	What to check
Improve the spreadsheet	Process is still changing and mistakes are manageable	Ownership, validation, sharing, recovery
Configure an existing app	A standard product supports the workflow	Permissions, export, integrations, licensing
Build an internal tool	Important rules or handoffs need a specific design	Maintenance, migration, adoption, support

This is an editorial decision framework, not a measured ranking of products.

A custom tool deserves consideration when a unique workflow is valuable enough to maintain. If a normal CRM or project management product already fits, configuring it may be the better investment.

A worked example: equipment requests

Imagine a fictional team tracking equipment requests in a shared sheet. Staff enter a description, a coordinator checks stock, and a manager confirms allocation.

The team keeps copying rows into email. Some requests show “approved” but do not name the person responsible for delivery. The issue is the handoff, not the grid itself.

A focused replacement could provide a request form, a stock-check queue, a decision history, and an assigned delivery owner. Reporting could still export to a spreadsheet. The first release would not need purchasing, payroll, or a complete asset platform.

Write that workflow into a custom application brief before selecting technology.

Measure the work you hope to improve

Use your own baseline. Record how long tasks take, how often information is re-entered, and how many requests need correction. Keep the measurement method consistent during the pilot.

For illustration, suppose a team handles 40 requests each week and manually copies information for five minutes per request. That step totals 200 minutes weekly. It is an estimate of the observed task, not a promise that software will save all 200 minutes.

Compare the expected benefit with development, licenses, hosting, training, maintenance, and support. Include work that will remain manual.

Plan the migration, not just the new screens

Choose which historical records must move. Identify duplicate rows, missing values, and records without a stable reference. Assign a business owner to resolve uncertain data.

Agree when the old file stops accepting updates. If both systems remain editable without a clear rule, the team may create a new reconciliation problem.

Pilot one workflow with representative users. Check that the new tool handles returns, cancellations, and unusual records. Keep an export and a practical fallback during the transition.

What should the first version include?

Start with data entry, the key decision, ownership, and a usable completion record. Add the permissions needed for that workflow. Define who can correct an error and what history must remain visible.

For request-based work, the approval automation guide explains how to describe these rules.

Bring KainoLab a redacted file and a real example of the handoff that fails. The team’s digital tools service provides a relevant starting point for discussing a focused replacement. Contact KainoLab with the process you want to improve.