A PO for $4,200 sits in your ops manager's inbox for six days. Nobody's ignoring it on purpose. It's just buried under forty other emails, three of which also need a "yes" from someone before Friday. Meanwhile the vendor calls twice, the ops manager forwards the thread to the CFO with "can you approve this?", the CFO replies-all with a question, and now there are two threads with slightly different context. This is what an approval workflow looks like at most SMBs: not a workflow at all, just email and Slack doing their best impression of one.
If this sounds familiar, you're not running a broken company. You're running a normal one. Somewhere between five and fifty employees, almost every business ends up routing approvals (purchase orders, time off, discounts, contract sign-off, expense reports) through whatever communication tool is already open. It works, sort of, until it doesn't.
Why your approval workflow ends up living in your inbox
Nobody sits down and designs this system. It accretes. In year one, the founder approves everything because there are twelve things a week that need approving and they all fit in one head. By year three there are 200 things a week, three people who can say yes, and the same inbox-and-hope process that worked at twelve requests now buckling under two hundred.
Email and Slack are attractive for approvals because they're already the place where work happens. Nobody has to log into a new tool. There's no training. A manager can approve a $500 expense from their phone between meetings. That low friction is exactly why the habit forms. It's also why it never gets replaced, even once it's actively hurting the business.
There's also a trust problem hiding underneath. Most SMBs don't have a real approval matrix: a documented answer to "who can approve what, up to what dollar amount, with what backup." Without that, email becomes the de facto system of record for a decision that was never actually formalized. The paper trail exists, technically. It's just scattered across three inboxes and impossible to search six months later when an auditor or a new controller asks "who approved this?"
Why the obvious fixes don't hold
The first instinct is usually "let's just be better about checking email." That lasts about two weeks. The volume didn't change; only the intention did.
The second instinct is a shared inbox or a distribution list, something like approvals@yourcompany.com. This helps exactly one problem (things don't get lost in one person's inbox) and makes two others worse: now everyone assumes someone else is handling it, and you still can't run a report on approval turnaround time without manually reading every thread.
The third instinct, and the one that burns the most money, is buying a full approval-workflow tool (a dedicated purchasing or procurement platform) before fixing anything upstream. We've watched companies spend $15,000 to $40,000 a year on software like this only to have adoption die within two months, because the tool assumes clean vendor data, a defined chart of accounts, and department codes that match the accounting system. If your QuickBooks vendor list and your Google Sheets budget tracker don't already agree with each other, a new approval tool just becomes a fourth place where the truth lives, not fewer.
The pattern is consistent: teams try to solve a data and process problem by buying a communication problem's cure. Slack is a communication tool. So is email. Approvals aren't communication. They're a decision with a record, a deadline, and consequences if it's wrong. Different job, different tool.
The real tradeoff nobody names out loud
Here's the part that doesn't get said in most software pitches: moving approvals out of email is genuinely disruptive for a few weeks, and the size of that disruption scales with how badly you've been avoiding structure. A company with a clean vendor list and clear spending limits can stand up a real approval flow in a week. A company where "who can approve a $10,000 contract" has three different informal answers depending on who you ask needs to have that argument first. And it is an argument, not a form-filling exercise.
That's the actual tradeoff: speed now, in exchange for continued chaos later, versus a slower start in exchange for a system that scales past the next hire. Most founders choose speed by default, not because it's the right call, but because nobody made them choose consciously.
A decision framework, not a mandate
Before you touch any software, answer these four questions. If you can't answer them cleanly, that's the actual problem, not the lack of a tool.
- Who can approve what, up to what dollar amount? Write it down. If it changes by person rather than by role, fix that first.
- What's the current average time-to-approval, and where does it stall? Pull ten recent approval threads from email and time-stamp them. Most teams have never measured this and are shocked by the number. It's usually 3 to 9 days for anything above routine spend.
- Where does the "source of truth" for the thing being approved already live? A PO relates to a vendor record. A time-off request relates to an HR system or a spreadsheet. If that record is inconsistent or duplicated across tools, no approval software will fix the approval, it'll just formalize the confusion.
- What happens after approval? Does someone re-key the decision into QuickBooks, into a project tracker, into payroll? If yes, you don't have an approval problem, you have a data-entry problem wearing an approval costume.
Only after those four are answered does it make sense to pick a tool, and often the answer isn't a dedicated approvals platform at all. It's adding structured approval steps to the system you already use for the underlying data: approval fields inside your CRM or ERP, a lightweight internal tool built on your existing database, or in some cases just a well-configured form that writes directly into the record instead of into an inbox.
What actually works, in practice
The businesses that get out of email-approval hell don't do it by buying the fanciest tool. They do it by connecting the request to the record it belongs to, so approving something is a status change on real data, not a reply to a message. A purchase request should live next to the vendor and budget line it affects. A time-off request should live next to the HR record and the calendar. When the approval and the data are the same object, you get an automatic audit trail for free. There's no separate log to maintain, because the history is just the record's history.
This is also the point where AI is genuinely useful, and where it isn't. An AI assistant that reads a pile of unstructured email threads and tries to guess "was this approved" is just guessing. It'll be wrong often enough that nobody trusts it. An AI assistant sitting on top of structured approval records, where every request has a status, an owner, an amount, and a threshold, can flag stale requests, summarize what's pending by department, or draft the follow-up message. Same underlying capability, wildly different reliability, because the second version has clean data to work from. The tool isn't the hard part. The structure underneath it is.
If this is the exact loop your team is stuck in (POs living in someone's inbox, approvals nobody can find in six months, a spending limit that exists only as tribal knowledge) it's worth mapping before you buy anything. We run a free 30-minute Process Teardown where we walk through one of your painful workflows end to end and put a number on the hours it's quietly costing you each month. No pitch, no obligation. You can see the kind of before-and-after we mean in our case studies, where a few SMBs went from scattered spreadsheets and inbox approvals to one connected system with automation and AI layered on top.
0 Comment