Manual approval chains slow deals down exactly when they’re gaining momentum. A deal can sit for days between quote creation and final sign off, not because anyone is being slow deliberately, but because nobody owns the handoff between sales, finance and legal. The fix isn’t a faster human, it’s removing the human from the routing decision entirely and only bringing them in to make the judgement call they’re actually needed for.
Why Approval Chains Break Down in the First Place
Most approval delays don’t come from a single slow approver, they come from the gaps between approvers. A quote leaves the sales rep’s hands and enters a space with no defined owner: it might sit in an inbox, a Slack thread, or a shared spreadsheet that only gets checked once a day. Nobody is failing at their job, but nobody’s job is specifically “move this forward either”, so it doesn’t move.
A second, quieter failure mode is approval overlap. Discount approval and commercial risk approval often live in separate policies but get bundled into one request, so a finance approver ends up making a legal judgement they’re not equipped to make, or vice versa. The rep, unsure who actually owns the decision, sends the request to whoever answered fastest last time rather than whoever the policy actually names. That habit becomes the de facto process, and it’s invisible until someone tries to document it.
The third failure mode is missing context. An approval request that says “please approve this quote” with a PDF attached forces the approver to go and find the information they need: what’s the standard list price, what’s the customer’s payment history, has this discount level been approved before for a similar account. Every one of those lookups adds hours, and they compound every time the request bounces back for clarification.
Mapping the Current Process Before You Touch a Tool
Before automating anything, document every touchpoint: who approves what, in what order, and on what information. This isn’t a box ticking exercise, it’s how you find out the process is not what the org chart says it is. Interview each approver separately rather than in a group session; people describe the official process in a group and the real one in private, and the gap between those two answers is usually where the delay lives.
Mapping this out routinely reveals redundant review layers: steps that exist because nobody has removed them since the process was first set up, not because they add value now. A common example is a legal sign off requirement that was added after one specific contract dispute years ago and has applied to every deal since, regardless of size or risk. Removing a step like that is a bigger win than automating it, because automating a step that shouldn’t exist just makes the unnecessary delay faster to reach, not shorter overall.
The Approval Audit Questions to Ask Every Stakeholder
Ask each approver four things, and write the answers down verbatim rather than paraphrasing: what threshold actually triggers your review (in their words, not the policy document’s), what information do you need in front of you to decide, what happens to requests when you’re on leave or unavailable, and how do you currently record that you’ve made a decision. The fourth question is the one people struggle with most, because the honest answer is often “I reply to the email” or “I don’t, really”, which tells you exactly where your audit trail gap is before you’ve written a single workflow rule.
Designing the Routing Logic That Replaces Manual Judgement
Automation turns approvals from a reactive bottleneck into something that runs on its own logic: routing by deal value or discount level, escalating automatically when a threshold is hit, and logging every decision so the audit trail is automatic rather than reconstructed after the fact. The design work here is deciding, in advance, exactly which conditions route to which approver, so the workflow never has to guess.
Threshold Based Routing by Deal Value and Discount
A workable tiered structure usually has three bands. Small, within policy discounts route straight to the deal’s sales manager, because that’s a judgement they’re already empowered to make and adding another layer just adds delay without adding scrutiny. Mid tier discounts, or anything touching non standard payment terms, route to a finance approver who can see margin impact against the account’s full commercial history. Large discounts, off list pricing, or anything with unusual contractual terms route to both legal and a senior commercial sign off, because those are the deals where getting it wrong is expensive in ways a discount percentage alone doesn’t capture. The point of defining bands this precisely is that the rep never decides who to ask; the deal’s own attributes decide it for them.
Escalation Paths and Timeout Rules
Every routing rule needs a matching timeout rule, or you’ve just moved the bottleneck instead of removing it. If an approver hasn’t actioned a request within an agreed window, the workflow should automatically notify a named backup approver rather than simply sending a reminder to the same person who’s already not responding. This matters more than it sounds: a reminder assumes the approver saw the first request and is choosing to delay, but in practice they’re usually just buried, and a second notification to the same inbox has the same fate as the first. Route the escalation to a different person or channel entirely.
One design trap worth naming directly: sending a request to several approvers in parallel “to be safe” usually makes things slower, not faster, because each approver assumes someone else is handling it. Sequential routing with a genuine timeout and escalation almost always outperforms parallel notification for this reason, even though parallel feels like it should be quicker.
Building the Workflow in n8n, HubSpot or Salesforce
The goal is one CRM integrated flow rather than approvals scattered across email threads and separate tools. Every stakeholder gets the right approval request, in the right order, without a human manually routing it each time. How you build that depends on how much of the logic needs to reach outside the CRM itself.
Where n8n Fits Versus Native CRM Approval Tools
Native approval tools, such as HubSpot’s workflow automations or Salesforce’s built in approval processes, are the right starting point when every piece of data the workflow needs already lives inside that CRM: deal value, discount percentage, owner, stage. They’re quick to build and every sales ops admin can maintain them without touching code. HubSpot’s own workflow documentation covers the trigger and action model these tools use, which is worth reading before you design your first rule set: HubSpot’s guide to creating workflows.
An orchestration tool like n8n earns its place when the logic needs to reach outside the CRM: checking a finance system for outstanding invoices before approving a further discount, posting a decision into a Slack channel and a compliance log at the same time, or triggering a document generation step once every approver has signed off. The tradeoff is real: n8n gives you cross-system logic a native CRM tool can’t, but it’s another system to maintain, monitor and secure, and if it goes down mid approval chain, deals stall in a place your CRM admin can’t see. n8n’s own documentation is the right reference point for understanding what a workflow node can and can’t do before you commit to it: n8n’s documentation. In practice, most mature setups end up using both: native CRM routing for the simple, in system decisions, and n8n as the layer that stitches CRM, finance and communication tools together for the more complex ones.
The Audit Trail: Turning Approvals into Compliance Evidence
An automated approval chain should produce a complete record without anyone having to build it separately: timestamp, approver identity, the decision itself, and a mandatory reason field for anything other than a straight approval. That last part matters more than it seems; a rejection or an override with no recorded reason is functionally the same as no audit trail at all when someone asks six months later why a particular deal got an unusual discount.
This is also where organisations most often confuse “we have a workflow” with “we have a compliant record”. A workflow that fires notifications is not the same as a workflow that retains a permanent, queryable log of who decided what and when, and the two need to be designed separately. If your business has any obligation to demonstrate decision making processes for regulatory or contractual reasons, it’s worth checking your record keeping approach against general guidance on accountability and documentation rather than assuming your CRM’s activity log is sufficient by default: the ICO’s guidance and resources for organisations is a useful starting reference for UK businesses thinking about this properly.
Common Failure Modes After Go-Live
The first failure is behavioural, not technical: approvers who spent years approving things by email keep checking email, and ignore the new in-system notification entirely until someone chases them. The fix isn’t a better notification, it’s a short transition period where the workflow sends both the new notification and a manual heads up, with an explicit date after which the manual heads up stops.
The second is threshold drift. Discount bands and deal value thresholds get set once, at launch, and then the business changes around them: pricing goes up, a new product line has different margin economics, a reorg moves who reports to whom. The thresholds baked into the workflow don’t update themselves, so six months in, deals are being routed against numbers nobody consciously chose, they’re just what was true at build time.
The third is scope creep in the wrong direction: teams add more parallel approvers “just in case” every time something slips through, which recreates the exact bottleneck the automation was built to remove. Every additional approver added to a chain should be justified by a specific incident, and reviewed for removal once the underlying risk is actually addressed some other way.
Sustaining the Improvement: Metrics That Matter
Track approval cycle time as an ongoing metric, not a one off fix. A workflow that speeds things up once and then quietly degrades as the business changes hasn’t actually solved the problem, it’s just delayed it. The most useful version of this metric isn’t a single overall number, it’s cycle time broken down by stage: time waiting in queue before an approver even sees the request, versus time the approver actually spends deciding once they’ve opened it. Those two numbers point to completely different fixes. A long queue time points to a routing or notification problem; a long decide time points to a missing context or information problem.
Assign a named owner, usually someone in RevOps, to review the workflow on a fixed schedule, not just when someone complains. That review should specifically check for threshold drift, unused escalation paths, and approvers who’ve left the business but are still named in the routing rules, since that last one is a surprisingly common way for a “finished” automation to quietly start failing months after launch.
Related Reading
RevOps Automation: The Complete Guide for where approval automation fits into the wider roadmap.
Sales operations consultancy for the automation layer this kind of workflow lives in.
For more on this, see our automation and n8n coverage, including Automate Demo Scheduling with N8N for Faster Sales, Boost SaaS Deal Velocity with Proven Sales Ops Automation Strategies, and Top n8n Workflows for Automating Sales Operations and CRM Efficiency.
Should discount approvals route in parallel to several approvers, or one at a time?
One at a time, in most cases. Parallel notification feels faster but usually causes each approver to assume someone else will handle it, which slows the decision down. Sequential routing with a genuine timeout and a named backup approver almost always resolves faster than sending the same request to several people at once.
Should we build approval routing natively in our CRM or with a tool like n8n?
Use your CRM’s native workflow tools when every input the decision needs already lives in that CRM, such as deal value or discount percentage. Reach for an orchestration tool like n8n when the logic has to check or act on systems outside the CRM, such as a finance platform or a compliance log, accepting that it adds another system you need to maintain and monitor.
What’s the most common reason an automated approval workflow degrades after launch?
Threshold drift is the most common cause. Discount bands and deal value thresholds are set once at build time and rarely revisited, so as pricing, products or reporting lines change, deals get routed against numbers nobody has consciously reviewed in months.
Do we need to keep a formal record of who approved each discount and why?
Yes, and a workflow that only sends notifications is not the same as one that retains a permanent, queryable log of the decision, the approver, and the reason given. This matters for internal audits and for demonstrating accountable decision making if your business has any regulatory or contractual obligation to do so.
What should we do before building any approval automation?
Map the current process first, interviewing each approver separately rather than in a group, and record their answers verbatim. This routinely reveals redundant review steps that exist for historical reasons rather than current risk, and removing those is often a bigger win than automating them.
Leave a Reply