The spreadsheet stayed. The weekly process left with the administrator.

A good spreadsheet can outlast the person who built it.

The formulas still calculate. Tabs are labelled. The colours make sense. Last month’s report is there, along with the one before it. A new employee opens the file and can see that someone knew what they were doing.

Then Tuesday arrives. A report needs to go out, a customer quote needs checking, or the bank needs reconciling. Nobody knows which export to download first, which inbox contains the late adjustments, why one job is treated differently, or what total should be checked before the numbers are sent. The workbook has survived. The working method has not.

Brendan Erofeev describes working with a business where jobs, quotes, reporting and reconciliation were handled in well-maintained spreadsheets. When the administrator left, the owners had the files but lacked instructions for the weekly work. This is a firsthand account, not evidence about how often it happens. It does describe a familiar handover failure: the visible file is mistaken for the whole process.

That distinction changes the response. Replacing every spreadsheet may be wasteful. Hiring an Excel specialist may solve an immediate problem while leaving the next handover just as exposed. First, find out what people do around the spreadsheet, what decisions they make, and what would let another person complete the cycle safely.

A spreadsheet can document a process

Excel is capable of holding useful documentation and automation. A workbook can include a start page, a glossary, an owner, a checklist, links to source reports, change notes, control totals and examples of completed work. It can contain named ranges that make formula logic easier to read. Comments and notes are supported in Excel, which makes them a reasonable place for short explanations close to a cell or calculation, provided somebody keeps them current. Microsoft’s guidance on comments and notes covers those options.

A macro can remove repetitive work. An external link can bring values from another workbook. Formula tracing can help a reviewer follow relationships between cells. Microsoft notes that tracing references across workbooks requires the other workbook to be open, which is a small but useful reminder that a formula diagram is only part of the picture.

The problem appears when the operating knowledge was never written down, or was recorded once and then left to rot. The workbook may say what last week’s answer was. It may say little about where the inputs came from, who approves a variance, what to do when a source file is late, or which number means the job is complete.

Some knowledge cannot live comfortably in a formula. It lives in access rights, timing, phone calls, email habits and judgement. One person knows that a supplier’s report arrives under a different name at month end. They know a negative balance is acceptable for two jobs but needs an owner’s approval for the rest. They know the macro fails if a downloaded file has an extra heading row. None of that is obvious from a tidy workbook.

Research on spreadsheet errors supports taking this seriously without resorting to scare statistics. Raymond Panko’s review of spreadsheet-error research discusses errors found in studied spreadsheets and the limits of proposed ways to reduce them. A small Irish study by Rittweger and Langan reported weak or unenforced controls among its participants and described a policy response in one organisation. Read it as a case-based study, not as a population estimate for every business. The practical lesson is simpler: a recurring workbook deserves review, ownership and a way for a second person to check the result.

What disappears when a person leaves

Start with the outcome, rather than the file. “Friday reconciliation” sounds like one task. In practice it might include an accounting export, a bank export, a report from the job system, three adjustments from email, a manager’s approval and a PDF sent to owners by midday.

The departing administrator may have carried the following details in their working routine:

the trigger for the task, its cut-off and the real deadline;
every input, including manual exports, attached files and the people who produce them;
the order of work across several workbooks or folders;
rules for matching, rounding, classifying and correcting items;
expected totals and the checks that catch an implausible result;
exceptions, who can approve them, and the point at which the task must be escalated;
access to shared drives, inboxes, source systems, macros and add-ins; and
where the approved output belongs and who needs it.

The missing information often reveals itself only under pressure. A replacement can refresh a workbook but cannot explain why the total has changed. They can produce a quote but do not know which prices need approval. They can paste in a report but cannot tell whether a row was intentionally excluded or lost during the export.

That is why a folder full of old files is weak handover material. It provides history. A new operator needs instructions for the next run.

A process can also be hidden across files. One workbook feeds another, which supplies a monthly pack. An input workbook may be manually renamed before an external link can find it. A staff member may open one file first because it refreshes calculations used elsewhere. Microsoft’s workbook-link guidance says links need maintenance and can need locating when they break. Include them in the handover material, along with dependencies that ordinary links will not reveal, such as emailed exports and manual copy-and-paste.

Treat the next live run as the source of truth

The fastest useful form of discovery is to watch the next real cycle. Sit with the operator while they complete the weekly report, quote review or reconciliation. Ask what they are doing before each step. Ask what would make them stop. Ask which result would make them call someone.

A screen recording can be useful where the business permits it, but a recording alone is not a runbook. It records clicks. The future operator also needs the reason for a check and the rule for an exception.

Capture the work in a simple process inventory. One line for each recurring outcome is enough to begin:

Process	Cadence and deadline	Operator	Deputy	Inputs	Output	Review	Key dependencies
Weekly cash reconciliation	Friday, 12 pm	Accounts administrator	Finance manager	Bank export, accounting export, job report	Approved reconciliation	Finance manager	Banking access, shared folder, reconciliation workbook

The entries above are an example. Your inventory needs the actual names, locations and responsibilities. Add the last successful run, consequence of a missed deadline, and whether the process involves sensitive data. That gives an owner a short list to work from instead of a vague instruction to “document the spreadsheets”.

For each workbook, record its purpose, authoritative location, owner, deputy, inputs, outputs, linked files, external data, macros, and downstream users. Record which access is held in a personal account or mailbox. Do not put passwords, API keys or other secrets in the register or the SOP. Transfer access through the organisation’s normal access process.

If a macro is involved, document its job in plain English. State how it is started, what it reads and writes, which version of Excel or other environment it depends on, what a successful run looks like, and what to do if it fails. Excel provides macro settings, including controls relating to trusted publishers and digital signatures, as described in Microsoft’s macro-security guidance. Those settings are useful controls. They do not explain the business rule inside the code or make the code maintainable by a successor.

Avoid the tempting clean-up project during a fragile handover. Take a dated copy, identify the current authoritative version, and set a sensible rule for changes. Keep operations moving. A formula rewrite, macro disablement or link tidy-up can wait until somebody has tested the present process and there is a rollback point.

Write an SOP that can run the work

An SOP, or standard operating procedure, needs to be specific enough that a capable colleague can complete a supervised run without being coached through hidden steps. It does not need to be beautiful. It needs to answer the questions that arise at 9.30 on a Friday when an input is missing.

A workable SOP has these sections:

Purpose and completion definition. Say who receives the result, by when, and what counts as complete. “Reconciliation sent to the finance manager with all differences either resolved or approved” is more useful than “update spreadsheet”.
People and escalation. Name the business owner, operator, reviewer, deputy and escalation contact. Use roles as well as names so the document survives personnel changes.
Trigger and preconditions. State the cadence, cut-off, folders, systems, reports and access required before work begins.
Steps and inputs. List the actual order of work. For each input, identify its source, expected date, format and a quick check that it is the right file.
Controls and evidence. Record control totals, matching rules, approval requirements and where evidence is saved. Include the checks that tell the operator the result is plausible.
Exception rules. Cover missing data, broken links, failed macros, mismatched totals, reruns and late approval. Say who may make a judgement call and when the work must stop for review.
Maintenance. Include the last-tested date, next review date and a small change record. Link the SOP from a visible start page in the workbook.

Here is a short example for a hypothetical Friday reconciliation:

Download the bank export after 8 am and save the untouched original in the dated input folder. Export the general ledger and job report using the stated date range. Confirm that the bank closing balance matches the balance on the downloaded statement before importing anything. Paste only into the marked input tabs. Check that the workbook’s bank total equals the statement total and that the ledger total equals the ledger export. Investigate every unmatched item above the agreed threshold. Items caused by a known timing difference can remain open only when the finance manager has approved the note. If the bank export has not arrived by 10 am, notify the finance manager and record the delay. Save the approved workbook and PDF in the dated output folder.

That example contains a sequence, checks, a threshold concept, an approval rule, a late-data rule and an evidence location. The actual SOP must fill in the real names, thresholds, folder paths and decisions. A screenshot can help with an awkward export. It cannot replace the rule that says whether an unmatched item is acceptable.

Put short explanations close to work that is likely to confuse the next person. A START HERE sheet can link to the SOP, list inputs and outputs, identify the owner and point to the change record. A small “what this tab does” note is often enough. Use the same ordinary language in the workbook and the SOP. If the worksheet calls something “Net job value” while the procedure calls it “Quoted revenue”, a new operator will lose time trying to prove they are the same thing.

Test the handover before it is needed

Documentation can look complete while failing in practice. The handover test exposes that early.

Choose a trained deputy or a capable colleague who did not build the process. Give them the current SOP, access to the required systems and the normal files. Have them run a supervised cycle, ideally on a non-critical copy or alongside the incumbent. The incumbent may answer factual questions, but should not take the keyboard for the difficult parts.

The reviewer should check four things:

Did the deputy find every input and get the right access?
Did they know which checks to perform and what result to expect?
Could they handle at least one realistic exception using the written rules?
Did the output reconcile, receive the required review and land in the right place?

Write down every pause, work-around and question. Those are defects in the SOP, permissions or workbook design. Fix them, then run the test again. A successful handover is a repeatable result, not a signed document.

This approach is close to the practical side of contingency planning. NIST’s contingency planning guide focuses on evaluating systems and operations and developing usable recovery guidance. Its federal context is broader than a small business spreadsheet, but the discipline transfers: plan around the work that has to continue, then test whether the plan works.

Keep the documentation alive. A repository is only useful if people can find it, trust it and update it during normal work. Atlassian’s explanation of knowledge management makes the useful distinction between storing information and maintaining it. Set a review date. Update the SOP whenever a source, role, macro, file path or approval rule changes. Ask the deputy to perform a supervised run after a material change, rather than assuming the existing document still fits.

Keep Excel where it fits, and spend carefully

Excel-skilled people deserve respect. Many businesses rely on them because they understand the numbers, the exceptions and the work itself. A spreadsheet may remain the sensible option for a stable, bounded process with a manageable volume of work, clear controls and more than one trained operator. A replacement system has costs of its own: discovery, data cleanup, migration, training, support and new failure modes.

The decision becomes harder when a process has many approvals, frequent changes, high-volume integrations, sensitive access, several concurrent users or material consequences if a result is wrong. Those conditions may justify workflow software, a purpose-built system, or a simpler division of work between tools. Make that decision from observed work, not from frustration with Excel or enthusiasm for new software.

Bringing in temporary Excel help can be a good use of a limited budget. Set the deliverables before work begins. Ask for an inventory, a dependency and macro register, runbooks, tested checks, a trained deputy and a handover test. If the engagement only produces a cleaner workbook, the business may still depend on one person.

Useful controls can also be modest. Store the authoritative workbook in a shared location rather than on one person’s device. Separate input tabs from calculations and outputs. Mark manual-input cells clearly. Keep a change record. Have another person review material formula or logic changes. Where your Microsoft setup supports it, Spreadsheet Compare can help reviewers see differences between versions. It is a review aid, not an approval process.

Choose controls in proportion to the risk. A small internal tracker may only need an owner, a deputy and a monthly check. A workbook that drives cash reporting or customer commitments needs tighter review, clear exception rules and recovery arrangements.

The point is continuity. A well-kept workbook can remain useful for years when the people around it can explain, run, review and recover the process. The weekly task should belong to the business, not to the last person who happened to know the clicks.

If you need help mapping the work around a spreadsheet, Ditch My Spreadsheet can provide structure analysis and recommendations using a synthetic example. Do not send confidential data. The aim is to make the questions and dependencies visible, then document and test the process with the people who own it.