Almost every operations team has one spreadsheet that quietly runs a part of the business. It tracks orders, maintenance, deliveries or staff schedules. It started as a quick fix, and now three people edit it and nobody dares to change a formula.
Our article on the spreadsheet problem in manufacturing describes how to recognise this situation. This one is the plan that comes after the diagnosis: how to replace one spreadsheet with a small internal tool in 30 days, without a large project.
Why 30 days is realistic
A small internal tool is not a new company system. It is a simple application with a login, a few forms, a list view and a handful of reports, used by one team. That scope is small enough to build in weeks, and small enough to throw away if the idea turns out wrong.
The limit of 30 days also protects you. A short deadline forces you to leave out features, and most spreadsheet features are rarely used. If the plan needs more than a month, the scope is probably too wide, and it is better to split it. For a wider view of what larger projects cost, see the real cost of custom software.
Week 1: pick one sheet and write down what it does
Choose the spreadsheet with the best mix of three things: a named owner, a visible cost, and a small group of users. A sheet used by five people in one department is a better start than a sheet used by the whole firm.
Then spend a few days on facts, not on design:
- Who edits the sheet, who only reads it, and how often?
- Which columns do people fill in, and which ones are empty or never read?
- Which formulas and colours carry real rules, such as "red means late" or "over 10 units needs approval"?
- Which reports or exports does somebody send to a manager every week?
- What goes wrong today: duplicate entries, overwritten cells, lost versions, wrong totals?
If you want a figure for the cost of the current way of working, measuring manual process cost in a week gives a simple method. You do not need a precise number. You need a number you can compare with at the end.
Week 2: decide what to keep, what to drop
Open the sheet with its users and sort every column and every rule into three groups.
- Core. Used every week, and the work stops without it. These go into version one.
- Later. Useful but not urgent. Write them on a list and do not build them yet.
- Drop. Empty columns, old experiments, duplicated data. Leave them in the archived sheet.
Most teams find that the core is 30 to 40 percent of what the sheet contains. That is the good news. The tool will be simpler than the sheet, which is part of the benefit.
Also decide three practical things now, because they are hard to change later: who may see and edit what, which fields are required, and where the data comes from on day one. Importing the existing rows is part of the plan, not an afterthought.
Weeks 2 and 3: build the core and let users try it
The build itself should take about two weeks. Keep it plain: forms for entering data, a list with search and filters, the two or three rules that were in the formulas, and the weekly report. Do not add dashboards, integrations or notifications in the first version.
Put a working version in front of two or three real users by the middle of the build. Ask them to do their normal Monday tasks with it, using copies of real data. Their complaints are more valuable than any specification. Change what blocks the work, and write the rest on the "later" list.
If you are unsure whether to build or to buy a ready product, five signs you have outgrown your software can help you check whether a standard tool would be enough. A small custom tool makes sense when the process is specific to you and off-the-shelf products would need more workarounds than the sheet does.
Week 4: switch on a fixed date
The most common failure is not a bad tool. It is a team that keeps using both. To avoid that, set the switch up like a small event:
- Choose one date, ideally at the start of a week, and tell everybody.
- Import the final data on the evening before.
- Make the old spreadsheet read-only on the same day, and keep it for reference.
- Name one person who answers questions for the first two weeks.
- Keep a short list of problems found in use, and fix the top ones within days.
A short training of 20 to 30 minutes is usually enough, because the tool has few screens. Show the three tasks people do most often, not every button.
A worked example (illustrative numbers)
The following example is calculated for illustration. It is not a client case.
Suppose a distribution team of six people tracks about 80 customer returns a week in one spreadsheet. Each return takes around 10 minutes to log and update, and the team spends about two hours a week fixing mistakes such as duplicate rows and wrong statuses.
- Logging and updating: 80 returns x 10 minutes = about 13 hours a week.
- Fixing mistakes: about 2 hours a week.
- Total: about 15 hours a week.
Assume the new tool uses a form with fixed choices and reduces the logging time to 6 minutes and the correction time to half an hour a week. That would be 8 hours of logging plus 0.5 hours of corrections, about 8.5 hours a week. The difference is about 6.5 hours a week, or roughly 28 hours a month.
If an hour of the team's time is valued at 25 euros, the saving is about 700 euros a month. Whether that justifies a build depends on the build price and on the value of fewer errors, which this example does not count. The point of the example is the method: measure before, estimate after, and check the estimate against real data.
Day 30: check whether it worked
On day 30, return to the numbers you collected in week 1 and compare them.
- Errors: how many duplicate or wrong entries were found, compared with the old sheet?
- Time: how long do the main tasks take now? Ask users and, if possible, time a sample.
- Use: is anyone still opening the old spreadsheet, and why?
- Requests: which items from the "later" list did people actually ask for?
The last point is often the most useful. Features that nobody asks for after a month probably did not need to exist. The ones that people ask for twice are your plan for the next month.
If the numbers did not improve, do not add features straight away. Look at where the process still depends on a person remembering something, and fix that first. For a team that finds the same patterns in a CRM, the CRM that became a glorified spreadsheet describes a related situation.
What to do next
Pick the one spreadsheet you would least like to lose, write down its owner and its weekly cost, and book the first week. If you want a second opinion on the scope before you start, a short discovery phase helps you decide what belongs in the first version, and what stays on the later list. Thirty days is enough to learn whether the idea works, and that is the real aim of the first version.