Most operations teams have one: the workbook that schedules the week, works out reorder quantities or splits the commission, and the one person who knows how it works. They're good at it, they've run it for years, and now they're retiring, changing roles or about to take three weeks off.
Start the handover now, while they're still here. Have them run it once on a recorded call, write down where every input comes from and where every output goes, keep a few past runs as tests, and have someone else run it while they watch. Then decide whether it should stay a spreadsheet at all.
What would it cost if they left tomorrow?
You don't need an estimate of the risk. You can describe it with your own answers:
| Question | Your answer |
|---|---|
| What the spreadsheet produces (a schedule, an order list, a pay figure) | |
| How often it runs | |
| Who receives the output, inside and outside the business | |
| What happens if the output is a day late, and a week late | |
| Hours a month the owner spends running it | |
| People who have run it start to finish in the last year | |
| Files, exports and systems it pulls from |
If the sixth row says one, you have a single point of failure. If the fourth row involves customers, payroll or a lender, the handover is urgent, not a nice-to-have.
Why do spreadsheets end up with one owner?
It rarely happens through anyone's fault. The usual causes:
- The person who cared most built it. It grew to fit how they think, with their shortcuts and their layout.
- Half the process lives outside the file. Downloading an export, pasting it into a tab, fixing three known problems by hand and emailing a PDF are all steps the workbook doesn't record.
- Hidden connections. Links to other workbooks, macros, hidden sheets and named ranges that only the owner knows to check.
- Judgment mixed with arithmetic. "I bump that customer's forecast up in December" is a business rule, but it lives in the owner's head and gets typed over a formula.
- It worked, so nobody else learned it. There was never a reason to train a second person until there suddenly was.
How do you capture it before they leave?
Treat this as a project with an end date, not a chat over coffee. Book the time on the owner's calendar.
- Record a normal run. With the owner's agreement, record a screen-share call while they run it for real and talk through each step, including the steps outside Excel. One recording of a real run is worth more than any written guide they'd produce from memory.
- Write a run sheet. A numbered list of every step: which file or export, where it comes from, what is done to it, what comes out and who gets it. The successor should be able to follow it without the recording.
- Trace the outputs that matter. Select a key result cell and, on the Formulas tab, in the Formula Auditing group, click Trace Precedents to see which cells feed it. Trace Dependents shows the reverse. Do this for each number someone outside the team relies on.
- Find links to other files. Select Data > Queries and Connections > Workbook Links to open the Workbook Links pane, which lists other workbooks this one pulls from. Each linked file is part of the system and needs an owner too. A file saved as .xlsm can also contain macros, which need the same treatment.
- Run a workbook report if you have Inquire. If your Excel shows an Inquire tab, its Workbook Analysis command, in Microsoft's words, "creates an interactive report showing detailed information about the workbook," including formulas and warnings.
- Write down the judgment calls. Ask the owner where they override a number and why. Each answer is either a rule that can be written down or a decision that needs a named person after they leave.
- Keep test runs. Save the inputs and outputs of the last three runs as read-only reference copies. Any future version, in Excel or in software, has to reproduce them.
- Shadow, then reverse. The successor runs it while the owner watches. Then the owner checks the successor's output against their own. Repeat until the results match without help.
- Put the master where versions are kept. "Version history in Microsoft 365 only works for files stored in OneDrive or SharePoint in Microsoft 365," Microsoft notes. A shared drive with no history means a bad save can't be undone.
When does doing it yourself stop working?
Sometimes the handover reveals that the spreadsheet should be retired, not passed on. The signs:
- The run sheet runs to pages of manual steps, copying and pasting between files.
- The successor can't reproduce the owner's results even after several shadow runs.
- Other people need the output daily, or customers see it.
- Several people need to update it at the same time.
- The inputs come from systems that can export or share data directly, and someone retypes them anyway.
- Most of the judgment calls turn out to be rules that could be written down.
At that point a spreadsheet passed from one person to the next will become a single point of failure again. Turning it into software puts the rules in one place, documented and tested against your saved runs, with logins and a record of who changed what. Our custom software page explains what that looks like, and our guide to how custom software gets built covers the stages.
What are your options?
| Option | What it looks like | Fits when | Watch for |
|---|---|---|---|
| Do it yourself | The capture steps above, plus a trained second person | A short run sheet and a successor with time to learn it | The new owner becomes the next single point of failure |
| Buy a tool | Off-the-shelf software for that job, such as a scheduling or inventory product | The spreadsheet does something common that a product does well | Losing the rules that made your spreadsheet fit, re-entering history |
| Hire a freelancer | An Excel specialist tidies and documents the workbook or turns it into a small app | The logic is sound and mostly needs structure | Documentation, who maintains it next year, ownership of anything built |
| An outside team that learns how you work and builds on your data | They sit in on the owner's runs, rebuild the job as software and check it against your saved runs | The process matters, several people depend on it and you want to own the result | Time from the owner before they leave; agree in writing what counts as a match |
What can you hand off, and what should stay with your team?
Hand off the mechanics: pulling the exports, the calculations, formatting the output, sending it to the right people and keeping a record of each run.
Keep the decisions: the overrides, the exceptions and the call on what to do when the numbers look wrong. Before the owner leaves, make sure each of those decisions has a named person attached, and that the owner has written down how they made them.
Questions to ask anyone you hire, us included
- How will you learn the steps that happen outside the spreadsheet?
- Will you test the new version against our saved runs, and what counts as a match?
- How much of the owner's time do you need, and by when?
- How will the judgment calls be handled: written into rules, or left to a person?
- Who owns the code, the data and the documentation?
- What happens when the process changes next year? Can our team make small changes?
FAQ
Can't we just hire a replacement who knows Excel?
You can, and for a simple workbook that may be enough. The risk is that you swap one single point of failure for another. Whoever takes over, do the capture steps first so the knowledge belongs to the business.
How long should the handover take?
Plan for at least two normal runs with the successor in charge and the owner checking, before the owner leaves. A monthly spreadsheet therefore needs to start months ahead, not weeks.
Should we rebuild the spreadsheet more cleanly in Excel?
If it's used by one person and runs rarely, a cleaner workbook with a run sheet is often the right answer. If several people depend on it daily, a cleaner spreadsheet still has the same weaknesses.
What if the person has already left?
Start with the saved outputs you have, the run sheet you can reconstruct and the formula tracing steps above. Rebuilding is slower without them, but past outputs still give you something to test against.