Spreadsheet workflow review before you rebuild anything

Why teams rebuild too soon

Teams see a messy spreadsheet and assume the spreadsheet is the problem. Most of the time, it is only the visible part of the problem. The real mess lives in how people make decisions, ask for approval, and patch gaps with side messages.

That is why a fast rewrite often fails. It moves the file into a new app but leaves the old process in place. The screens look cleaner, yet the same delays, confusion, and last-minute fixes keep showing up.

A useful spreadsheet workflow review starts with a plain question: what job is this file doing every day? In many teams, the spreadsheet does far more than track rows and totals. It acts as a queue, a reminder system, a rough policy manual, and sometimes a place where people quietly correct bad data.

The hardest part is that many rules do not live in the file at all. Someone keeps a private note for one customer. A manager approves something by email. A teammate drops a "use the old price for this one" message in chat. If you rebuild before you collect those exceptions, the new system breaks almost immediately.

One missing approval step can stall the whole flow. A finance team might enter purchase requests in a spreadsheet, send a message to a department lead, then wait for someone else to confirm the budget. If the rebuild captures the form but skips that budget check, requests pile up fast and people fall back to manual work.

Teams also rebuild too soon because they want relief now. That makes sense. Spreadsheets feel fragile when five people edit them at once, formulas keep breaking, and nobody trusts the final number. But speed can trap you. If you turn every workaround into code, you lock old habits into the new system and make them harder to remove later.

A short pause before coding saves time. Watch the workflow for a few days. Ask who changes what, who approves what, and where exceptions show up. That small delay often prevents months of rebuilding the wrong thing.

What the spreadsheet does today

Start with the messy version, not the tidy story people tell about it. Teams often say they have one spreadsheet. In reality, they have one spreadsheet, three exports, a copied monthly file, and a trail of side notes in chat or email. A spreadsheet workflow review works only when you map the real work instead of the official process.

Open the file and list everything people touch: tabs, filter views, CSV exports, copied files, and any workbook people duplicate each week or month. If finance downloads one tab on Friday and ops pastes it into another workbook on Monday, count both steps.

Then name the people involved. Write down who edits each area, how often they touch it, and what usually triggers the update. One person may enter leads every morning. Another may clean rows before invoicing. A manager may only open the file at month end. Timing matters because many rebuilds fail on small habits, not on big logic.

Track the data from start to finish. Note where it first appears, who checks it, what formulas or manual edits shape it, what gets exported or copied elsewhere, and where it ends up after the spreadsheet. That sounds basic, but it usually exposes the real work.

A small team may think its customer list lives in one workbook. In practice, sales updates the main tab, support fixes statuses in a copied file, and the founder pastes totals into a board report. Miss those side steps and the rebuild will still break daily work, even if the new app looks fine.

You also need to capture the work outside the spreadsheet. Ask people what they do in email, chat, notes, calendar reminders, or their own scratch files before they touch the sheet or after they leave it. Some teams check order details in an inbox, call a supplier, then return to the spreadsheet to mark the row done. The spreadsheet stores the result, but the work happens elsewhere.

Oleg Sotnikov often reviews operations by tracing how people actually use a process, not how they describe it in a meeting. That habit saves time. Once you see the whole path, you stop rebuilding a file and start fixing the workflow around it.

Sort temporary fixes from durable rules

A rebuild goes wrong when a team treats every spreadsheet formula, color, and side note as a permanent rule. Most sheets carry old repairs for old problems. If you copy all of that into software, you freeze yesterday's mess into tomorrow's process.

Start by marking anything that appeared as a patch. Maybe someone added a manual column after a customer dispute, or wrote a warning note after one late invoice. Those changes may have helped at the time, but that does not mean they belong in a new system.

Some rules do belong. Keep the ones that protect money, legal terms, delivery promises, or approval limits. If a step exists because it stops duplicate payments, catches pricing errors, or confirms who approved a refund, keep it under review. Those rules protect the business, not just the spreadsheet.

A lot of teams confuse habit with need. People may say, "We always export this tab on Friday," when the real need is much smaller. Maybe one manager just wants a weekly number and no longer needs the full file. That is why a business rules audit should ask what decision each step supports, not just who touches it.

A simple test helps. For every odd rule or workaround, ask what problem it solved, whether that problem still exists, whether cleaner source data would remove the step, what breaks if you delete it, and who would notice first.

Small examples make this easier to judge. A sales team may keep a "double-check" column because product names used to change mid-month. If product names now come from one clean source, that column is dead weight. On the other hand, manager approval for discounts above 15% probably stays. That rule is about margin control, not spreadsheet history.

An outside CTO should push for plain answers. If nobody can explain why a rule exists, treat it as temporary until someone proves it matters. That habit alone can cut weeks from a rebuild and keep the new tool much simpler.

Map approvals and handoffs

Most spreadsheet processes break around waiting, not data entry. A team may finish the work in ten minutes, then lose two days because one manager needs to approve a discount, finance checks the budget, and nobody knows who should follow up.

Put every approval in order. If two people can approve at the same time, note that too. Do not write "management" or "finance" as the approver. Name the role, or the person, who gives the yes or no. Also note who steps in when that person is away.

For each approval, capture four facts: what triggers the review, who decides, what counts as approval or rejection, and where the item goes next.

This kind of approval process mapping exposes hidden rules fast. A discount above 15% may need a sales lead. Above 25%, it may need the founder. Orders submitted after 4 p.m. may move to the next day. A rush request may skip one step but still need a note for finance. These thresholds, cutoffs, and exception paths matter more than most teams expect because code will turn them into fixed behavior.

Mark every place where work waits for a reply. Use the real delay, not the hoped-for one. If legal usually answers in one day but finance often takes three, write that down. Waiting points show where automation will help and where software will still pause for a human.

Handoffs need the same care. Note what the next person receives, how they receive it, and what makes them send it back. A clean handoff might look simple: sales enters customer details, finance checks payment terms, and operations schedules delivery. But if operations often chases missing fields, the problem is not the spreadsheet. The handoff is weak.

This exercise often shows that only one or two approvals are real. The rest are habits copied from old fixes. Keep the approvals that protect money, risk, or compliance. Question the ones that only slow the team down.

Run the review step by step

Start with one real case, not a guessed version of the process. Pick a recent item that moved all the way through the spreadsheet, from the first entry to the final approval or handoff. A live example exposes the workarounds people forget to mention when they describe "how it usually works."

Then talk to every person who touched that case. Keep the questions simple. What did you receive? What did you change? What made you stop and ask someone else? People often skip small steps because they feel obvious. Those small steps are usually where rebuilds fail.

Keep the review concrete. Open the actual row, tab, or file used in the case. Trace every change in order, including emails, chats, and side notes. Write down who made each decision and why. Mark any step that depends on memory, judgment, or a manager's quick reply. Also note what happens when data is missing, late, or wrong.

Put the whole flow on one page. A simple diagram is enough if it shows who starts the work, who checks it, where approvals happen, and where the process leaves the spreadsheet for a call, message, or another tool.

Then review that draft with the same people in one short session. Do not start with opinions. Walk through the case from start to finish and let people stop you when the draft misses a branch, exception, or delay. Hidden rules usually appear here, like "finance only checks orders above a certain amount" or "sales can fix this field, but only before noon on Friday."

Before anyone writes specs, freeze the current process. Save the agreed version with a date. Name an owner. Tell the team not to quietly add new exceptions while planning starts. If the target keeps moving, the rebuild turns into guesswork, and guesswork gets expensive fast.

A simple example from a small team

A small sales team keeps every quote in one shared spreadsheet. It looks simple at first. Each row has a customer name, price, expected close date, and a discount field that reps edit when they need to move faster.

Finance uses the same file differently. They check discounts in a separate tab, compare them with margin targets, and flag anything that looks too aggressive. The sales team sees the sheet as a quote tracker. Finance treats it as a control point.

That difference matters when someone wants to rebuild the workflow in a proper app.

At first, the team asks for obvious things: a form for new quotes, a dashboard, and automatic status updates. Those are reasonable requests. The trouble starts with the rule nobody wrote down.

Large deals need manager approval, but that approval does not happen in the sheet. A rep sends an email to the sales manager, the manager replies with a short "approved," and then the rep updates the row by hand. Sometimes finance checks for that email. Sometimes they trust the rep's note in the comments column. Everyone knows this rule, but the spreadsheet never states it.

If a developer rebuilds the process without that step, the new app can break the business on day one. Reps may submit big discounts with no approval record. Finance may stop trusting the numbers. Managers may move approvals into chat, phone calls, or memory because the old habit disappeared and no replacement exists.

A good review separates the process into parts. The comments field may be a temporary fix. The discount threshold is a real rule. The email itself does not need to survive, but the approval record does.

This is where an outside CTO often helps most. A fresh set of eyes can ask one plain question: "If the email goes away, what proves the deal was approved?" That question alone can save weeks of rework and a lot of awkward calls between sales and finance.

Mistakes that waste time

A spreadsheet workflow review often goes off track for one simple reason: teams talk to the person who owns the file and stop there. That person knows the sheet, but not always the whole process. The approver, the backup person, and the person who fixes mistakes at 6 p.m. usually know more about where the work actually breaks.

One sales ops sheet might look clean when the owner explains it. Then finance says two columns only matter at month end, and the team lead says one hidden tab exists only because a manager wanted a weekly summary last year. If you only interview the owner, you rebuild their version of the truth.

Another common waste is copying every column into the new tool without asking why each one exists. Old spreadsheets collect leftovers. Some fields helped with a one-time import. Some were added for a rushed client request. Some are manual notes that nobody reads.

When teams skip that question, they turn old clutter into new software. That gets expensive quickly.

Exceptions cause even more damage. Teams like to describe the normal path because it sounds tidy, but the ugly cases drive most of the real work. Month-end close, urgent orders, missing documents, late approvals, and temporary overrides all change the rules.

If the rebuild ignores those moments, people go back to side messages and manual fixes in week one. The new system then looks broken even when the code works exactly as written.

Reporting needs also get mixed up with approval needs. A manager may want a field for a dashboard, while an approver needs only three facts to say yes or no. Those are different jobs. Blend them together and screens get crowded, forms get longer, and approvals slow down.

The biggest mistake is starting automation before the rules stop moving. A business rules audit does not need months, but it does need clear answers. Who can approve what? What changes under pressure? Which rule is permanent, and which one is just a workaround from last quarter?

A good outside CTO usually pushes back here. Waiting a few days to settle the rules can save weeks of rework, awkward hand edits, and one more spreadsheet that nobody wanted to keep.

A quick checklist before code starts

Most rebuilds go wrong before anyone writes code. The team skips the messy parts, then discovers later that the spreadsheet was hiding ownership gaps, silent approvals, and workarounds nobody meant to keep.

The review should end with one clear picture of how work moves today. If two people describe the same process in different ways, stop there. A new system will only freeze the confusion in place.

Before you approve any rebuild, check five things:

• Every input has one owner. If a number appears in the sheet, you should know who enters it, who checks it, and who fixes it when it is wrong.
• Every approval has a reason. Some approvals protect money, risk, or customer promises. Others survive only because nobody removed them.
• Frequent exceptions are written down. If the team handles the same edge case every week, it belongs in the plan.
• Reporting fields are separate from approval fields. Decision screens should stay lean.
• The current process is frozen. Once planning starts, people should not keep adding quiet side rules.

That is enough for most small teams. If you cannot answer those points clearly, the rebuild is not ready.

What to do next

Once you have the workflow on paper, make a hard call on every step: keep it, simplify it, or cut it. Teams often keep old checks, duplicate fields, and extra approval hops long after the reason is gone. If nobody can explain why a step exists, it should not make it into the first rebuild.

Then write a short spec in plain language. Keep it tight. Note the rules that must stay, who approves what, what data goes in, and what output people need at the end. For most small teams, this fits on one or two pages.

A simple filter helps. Keep rules tied to money, compliance, customer commitments, or real risk. Delay rare exceptions until the main flow works. Remove steps that only copy data from one place to another. Mark approvals that exist only because people do not trust the current process.

That last point matters more than most teams expect. A weak process collects approval layers over time. Rebuilding it without fixing the trust problem just moves the same mess into new software.

Do not start with a full rewrite. Pick one part that causes delays every week, release that first, and watch what happens. A small launch exposes missing rules quickly. A big launch usually hides them until people are already stuck.

If the team cannot agree on what is temporary and what is a real business rule, bring in someone from outside. An outside CTO can cut through old arguments because they are not defending the current spreadsheet or the last failed tool choice. They can ask plain questions, spot waste, and turn a messy process into a plan people can actually build.

If you need that kind of review, Oleg Sotnikov at oleg.is works with startups and small teams on process cleanup, technical planning, and AI-first operations. A clear document, one small release, and one owner for each approval step will usually save more time than another rushed rebuild.