I’ve been in IT for over 25 years, and I’ve lost count of how many times I’ve seen this: a team needs to track requests, so someone builds a tracker in Excel. Then they need approvals, so the file starts circulating by email. Before long, that one workbook is the fragile cornerstone of an entire department’s operations.
Excel is brilliant at what it was designed for. It’s a terrible process engine. If your team is living in a mix of email threads and shared spreadsheets to get work approved, you don’t have a workflow. You have a bottleneck with a .xlsx extension.
Here’s what that actually costs you, how I think about building a real approval system, and what I’ve learned the hard way shipping these things in production.
## The Hidden Cost of Email-and-Excel “Workflows”
The price of running approvals through inboxes and attachments never shows up as a line item. But it shows up every single day in lost time, mistakes, and frustration.
1. Version control nightmares
Email a spreadsheet to five managers and you get five competing truths. Now try merging those back together. It’s manual, it’s tedious, and it’s practically designed to produce mistakes.
2. The approval black hole
Requests sink in the inbox. A critical approval sits for a week because someone’s on leave and the email is buried under fifty others. Nobody knows it’s stuck until someone downstream starts asking questions.
3. Zero auditability
When an auditor asks who approved what and when, you’re reconstructing history from months of Outlook archaeology. That isn’t a record. It’s a scavenger hunt.
## Designing a Multi-Step Approval System
Getting out of file-chasing mode means you stop optimizing the spreadsheet and start modeling the actual system. A solid workflow stands on three pillars:
- States—where an item currently sits, unambiguously: Draft, Pending Manager Review, Pending QA, Approved, Rejected.
- Transitions—the named actions that move an item from one state to the next.
- Roles—who’s allowed to fire which transition. A standard user submits; a manager approves; a QA lead signs off on compliance items.
Everything else—notifications, dashboards, reporting—hangs off that model. Get this right and the rest follows naturally.
## Visualizing the Flow
Before I touch any UI, I sketch the state machine on paper. It forces the messy human process into something concrete that you can actually implement and test.
Here’s a simplified routing sketch that branches between a standard path and a stricter compliance path—the kind of thing you’d see in manufacturing where ASME-certified work requires an extra sign-off:
[State: Draft]
|
+-- (Action: Submit) --> [State: Pending Manager Review]
|
+-- (Action: Reject) --------> [State: Draft]
|
+-- (Action: Approve)
|
[Is this an ASME item?]
|
+--------------------+--------------------+
| (No) | (Yes)
v v
[State: Final Approval] [State: Pending QA Review]
|
+-- (Action: Reject) --> [State: Draft]
|
+-- (Action: Approve)
|
v
[State: Final Approval]
## Edge Cases: ASME vs. Non-ASME Flows
In the real world, not every request follows the same path. A routine internal request might only need a manager’s sign-off. An ASME-related workflow carries regulatory weight—the wrong person signing off isn’t just a process gap, it’s a compliance failure.
When I build this into an app, I make the routing conditional on data the user already entered. If a part is flagged as ASME, the manager physically can’t shortcut to final approval. The workflow forces it through a dedicated QA review first. The system enforces the rules so humans don’t have to remember them—and removes the failure mode where someone simply forgets to loop in compliance.
## Lessons from Building Real Workflows
Moving a team from manual spreadsheets to a structured web app teaches you a few things about human behavior that no architecture diagram will prepare you for.
1. Build the happy path first
Don’t try to handle every edge case in version one. Map the most common successful path, make it bulletproof, then layer in the exceptions. Perfect coverage of edge cases on day one is how you never ship anything at all.
2. Audit trails are non-negotiable
Every transition should log who acted, when, and what changed. This turns your app from a request router into a defensible system of record. When questions come—and they always do—you have answers.
3. Users will bypass what hurts
This is the one people underestimate. If the new tool is harder than the old spreadsheet, people will route around it with email and pretend the app doesn’t exist. The UI has to be bluntly obvious: a dashboard that shows what needs attention, an Approve button that’s easier to find than the workaround.
## How I Build These
In practice, I build these as web apps using the same stack I use for everything: Next.js and TypeScript for the UI and API, Prisma for a clean data model—requests, states, assignments, audit rows—and real authentication so every action ties back to a real person. The stack doesn’t change project to project. The domain rules do.
## Final Thought
A spreadsheet can hold data. It can’t hold accountability. When the stakes are real—compliance, audits, regulatory sign-offs—you need defined states, enforced roles, and a trail you can stand behind. Not another email attachment with five filenames ending in _FINAL_v3.xlsx.
Replacing spreadsheet chaos with a structured app takes effort. The trade is worth it: fewer bottlenecks, compliance enforced by the system instead of by memory, and hours given back to people who shouldn’t be playing inbox detective.