From Spreadsheet to System: Migrating Manual Processes to Automation

Every small business has one: a shared spreadsheet that has quietly become a critical business system. Nobody knows who owns it. Data gets lost. It breaks regularly. It needs to be replaced — but you can’t just shut it down while people are using it.

Migrating a spreadsheet to automation is risky. You can’t flip a switch. People are depending on it. If the new system fails, you’re liable. You need a process that doesn’t disrupt operations.

Here’s how we do it.

Step 1: Shadow the Workflow (2–3 hours)

Don’t look at the spreadsheet first. Watch the human using it.

Sit with whoever touches it most. Ask:

• What triggers you to use this spreadsheet? (Daily? When a customer request comes in? Quarterly?)
• What do you look at first?
• How do you decide what to do next? Are there decision rules — “If the amount is over $X, I do Y”?
• What do you check before you save?
• When does it break? What happens?
• How often do you manually fix things?

Take notes. You’ll hear things the spreadsheet itself won’t tell you.

Step 2: Map Decision Points

Not every cell in the spreadsheet is important. Most of it is output or intermediate math. Find the decision points — the places where a human makes a judgment.

Using the past-due example:

• Input: Customer name, invoice date, payment status.
• Decision 1: Is the invoice 30+ days past due? (Yes/No)
• Decision 2: If yes, what priority should we assign? Depends on customer history and relationship.
• Decision 3: Should we flag for manual review? Depends on decisions 1 and 2 plus business rules.
• Output: Flag, priority, notes for the collections team.

Those decision points are where AI shines. Claude can read context — customer history, notes, relationship — and make a judgment that a formula can’t.

Step 3: Identify the 80/20 Automation Target

Not every spreadsheet should become a fully automated system. Ask: “What if I automated 80% of this and left 20% for manual work?”

• 80%: AI reads invoice data and payment history, flags past-due accounts, assigns priority.
• 20%: Collections team reviews flagged accounts and sends notices. They decide tone, timing, and forgiveness based on the actual conversation.

Why keep the 20% manual? Because relationship and judgment matter. A past-due customer might have already called and explained. The spreadsheet doesn’t know that. Trying to automate everything is how automation projects fail.

Step 4: Design the New System (Without Shutting Down the Old)

Build a parallel system. The spreadsheet keeps running. The new system runs alongside it.

Old system: Shared Google Sheet. Every Friday, manually export data, match against invoices, flag past-due accounts.

New system:

• DynamoDB stores customer records, invoice data, and past-due status.
• Lambda runs Friday morning, analyzes invoice data, flags past-due accounts.
• Slack notification alerts the collections team with a prioritized list.
• Web dashboard lets the team review flagged accounts, take action, and log outcomes.

Both systems run for 1–2 weeks. The team uses the spreadsheet like before. They also get the Slack notification and check the dashboard. They compare. Do the results match? Is the dashboard right? Once the team trusts the new system — usually 2–3 weeks — they stop using the spreadsheet.

Step 5: Handle Edge Cases

After 1–2 weeks of running in parallel, the team will say: “The automation flagged X, but actually this is a special case because...”

You now have a list of edge cases. Examples:

• “This customer is past due but they’re switching payment systems this week.”
• “We should flag anyone over 60 days, not just 30.”
• “This customer is a VIP. Don’t flag them even if they’re past due.”

Add those rules to the automation. Some are simple threshold changes. Some require a manual override the team can trigger from the dashboard. You’ll never catch 100% of edge cases upfront. That’s why running in parallel is crucial.

Step 6: Retire the Spreadsheet (Safely)

Once the automation is handling 99% of cases and the team is confident:

1. Archive the spreadsheet (don’t delete it).
2. Document the new process.
3. Set a checkpoint: “In 30 days, we’ll delete the archive if there are no issues.”
4. Usually, by then, nobody misses it.

Real Example: Vendor Payment Approval

Old system: Weekly spreadsheet review. Manager looks at vendor invoices, checks if they match purchase orders, approves or rejects with notes. Takes roughly 2 hours per week.

New system (3-week build):

• Invoices land in S3 (from vendor email or manual upload).
• Lambda processes each: extracts vendor, amount, invoice number.
• Claude reads the invoice, matches against PO database.
• If match: auto-approve and route to accounting system.
• If no match: Slack the manager — “Invoice from Acme for $1,200 doesn’t match any PO. Approve or reject?”
• Manager clicks Approve or Reject directly in Slack.

Common Mistakes to Avoid

Automating a broken process. You automated something, but the human process was inefficient to begin with. Before automating, check whether the process itself needs to change first.

Building in a vacuum. You deliver a system and expect adoption. Instead, involve the user from day one. They should see the new system running in parallel and have input into what it flags.

Over-automating edge cases. Some decisions should stay manual. Automate the 80%, keep the 20% human. Fighting every edge case in code costs more than it saves.

Shutting down the old system too fast. Always run in parallel for at least 1–2 weeks. Build trust before you pull the plug.

The Timeline

For most small business automations, expect:

• Week 1: Shadow, interview, document the workflow.
• Week 2: Design the new system.
• Weeks 3–4: Build.
• Weeks 5–6: Run in parallel, collect feedback.
• Week 7: Retire the spreadsheet, go live.

Four to six weeks from “we need to fix this spreadsheet” to “the spreadsheet is gone and the system is running.” That’s a reasonable timeline for most teams — fast enough to matter, slow enough to do it right.