Three approvals, one email thread, and nine days later the contract is signed with nobody able to reconstruct who approved which version. Here is what to look for in a routing tool.
A vendor agreement needs three approvals: legal, the budget owner, and finance if the annual value clears 50,000 dollars. Right now that happens by email. Someone attaches the PDF, adds three people to the To line, and writes "approvals please." Legal replies with two questions. The budget owner replies to a version of the thread that does not include finance. Finance approves a version that legal had already asked to change. Nine days later the contract is signed, and nobody can reconstruct who approved what.
Multiply that by the 40 or so agreements your team pushes through per month and you have a rough estimate of what broken document routing costs you: not in software, in cycle time, rework, and the audit exposure of an approval trail that lives in four people's inboxes.
If you are evaluating a document routing workflow solution, this is what to look at and what the demos will not tell you.
Document routing is the automated movement of a document through a defined sequence of people and systems, with each stop having a purpose, an owner, and a recorded outcome.
The three words that matter are automated, defined, and recorded.
Automated means the handoff happens without someone deciding to make it happen. Email is not routing, because every hop requires a human to remember who is next.
Defined means the path exists before the document enters it. If the route is worked out ad hoc per document, you have a convention, not a workflow, and conventions vary by who is running them.
Recorded means every decision is captured with actor, timestamp, and the specific version acted on. This is the part organizations discover they need during an audit or a dispute, which is late.
Routing is distinct from a few adjacent things it gets confused with. It is not e-signature, which is one possible final step. It is not document management, which is about storage and retrieval. It is not full workflow automation across your business, which is a much broader category. Routing is specifically about getting a document in front of the right people in the right order and knowing what they decided. Our broader piece on document workflow automation covers the wider category if routing turns out to be only part of your problem.
Most teams know routing is imperfect and are not sure it is bad enough to fix. These are the diagnostic signals.
You cannot answer "where is it" without asking someone. If determining a document's status requires a Slack message, there is no system of record for status, and every stakeholder is running their own mental tracker.
Approvals arrive on the wrong version. This is the most expensive symptom, because it produces approvals that are legally and practically worthless while looking valid.
The same document gets stuck at the same step repeatedly. A consistent bottleneck is usually not a slow person. It is a step that lacks the information needed to decide, or an approver whose approval is not actually required.
Sequential approval for things that could be parallel. If legal, finance, and the budget owner each review independently and none depends on the others, running them in series triples the cycle time for no reason.
Everything routes the same way regardless of risk. A 2,000 dollar renewal following the same path as a 400,000 dollar master agreement means either the small one is over-controlled or the large one is under-controlled. Usually both.
Nobody can produce the approval trail on request. If reconstructing who approved what requires searching email, you have an audit finding waiting to happen.
Almost every real workflow is a combination of three primitives. Knowing which ones you need is the single most useful piece of preparation before a vendor conversation.
Sequential. A, then B, then C. Use when each reviewer needs the previous one's output. Legal should review before finance if legal's changes affect the numbers. Sequential is the slowest pattern and the default that most email-based processes fall into by accident rather than by design.
Parallel. A, B, and C simultaneously, with the document advancing when all have responded or when a quorum is met. Use when reviewers are independent. This is the single biggest cycle time reduction available to most teams and it is frequently unavailable in cheaper tools, which is worth checking before you buy.
Conditional. The path depends on the document's attributes. Value over a threshold adds finance. Non-standard liability terms add the general counsel. A specific counterparty type adds security review. Conditional routing is what lets you apply real scrutiny where it matters without imposing it everywhere, and it is where evaluation should focus, because implementations vary enormously in how much logic they support.
The question to ask in a demo is not whether the tool supports conditional routing. Everyone says yes. It is how conditions are expressed, whether a non-engineer can change one, and what happens when a condition references a field that is empty.
Ranked roughly by how often they turn out to matter after purchase rather than before.
Version binding on approval. When someone approves, the system must record which specific version they approved. If the document changes afterward, prior approvals should either invalidate or be visibly flagged as stale. Tools that treat approval as a status on a container rather than on a version will let you collect approvals on a document that has since changed, which is the failure that started this article. Ask this question first.
Parallel and conditional routing without engineering. If changing the approval threshold from 50,000 to 75,000 dollars requires a support ticket, the workflow will not stay current with the business, and within a year people will be routing around it.
Delegation and absence handling. Approvers take holidays. Without built-in delegation, every absence becomes a stalled document and someone eventually shares credentials, which is worse than the original problem.
A real audit trail. Actor, action, timestamp, version, and comment for every event, exportable, and immutable. "We have activity logs" is not the same thing. Ask to see an exported trail for a completed document during the demo.
Reminders and escalation. A pending approval with no reminder is a document that stops. Escalation to a manager after a defined period is what turns a workflow from a queue into a process.
Visible status to everyone with a stake. The requester should be able to see where their document is without asking. This single feature eliminates a surprising volume of internal messaging.
Integration with where the document lives and where it goes. Routing that requires downloading, uploading, and re-uploading creates version divergence at every boundary. The integration questions that matter are with your document store, your signature tool, and your system of record for the underlying transaction.
Handling of changes mid-flight. Real approvals produce edits. What happens when approver two wants a change after approver one has signed off? Tools handle this on a spectrum from restarting the whole workflow, which is safe and slow, to silently continuing, which is fast and wrong. The right answer is usually configurable partial restart, and many tools do not offer it.
These are phrased to be difficult to answer with a marketing response.
"Show me an approval that was granted, then the document changed, then what the audit trail looks like."
"Change a routing condition live, in this demo, without a developer."
"What happens when a required approver has left the company and their account is deactivated mid-workflow?"
"Export the complete audit trail for a finished document and show me the file."
"How does an external counterparty participate, and do they need an account?"
"Two people edit at the same step simultaneously. What happens?"
"Show me the average cycle time report broken down by step for an existing customer."
The gap between how confidently a vendor answers the first three and the last four is usually informative.
Two areas that get underweighted during evaluation and dominate the experience afterward.
Integration. The question is not whether integrations exist but what direction data flows and what is authoritative. If the routing tool holds a copy of the document while the source of truth is elsewhere, you have created a synchronization problem that will produce version divergence. Prefer architectures where routing operates on the document in place rather than on a copy. Where that is impossible, know exactly which system is authoritative at each stage and make sure everyone else does too.
Audit. If you operate under SOX, ISO 27001, SOC 2, GDPR, or a sector-specific regime, your auditors will ask for evidence of approval controls. The practical requirements are consistent: the trail must show who approved, when, what version, and that the approver had authority to do so. Trails that show approval without version binding fail this test. Trails stored in a system where an administrator can edit history also fail it. Ask specifically whether administrators can modify or delete audit records, and treat a vague answer as a no.
Building an ROI case for routing is straightforward if you measure the right things and resist the temptation to claim the big numbers.
Cycle time, measured per step. Total time is the headline. Per-step time is where the actionable information is, because it identifies which approval is actually the bottleneck rather than which one people complain about.
Touch count. How many human actions move one document end to end. Every automated handoff removes one, and this is the number that compounds.
Rework rate. Percentage of documents that go backward in the workflow. High rework usually means an early step lacks information, not that a later reviewer is difficult.
Approval-on-stale-version rate. Measure this before implementing. It is usually higher than anyone expects and it is the risk number that makes the case to a general counsel more effectively than cycle time does.
Time to produce an audit trail. If it currently takes half a day of email archaeology per document, and you get asked for twenty during an audit, the arithmetic is easy.
The honest ROI framing: routing does not usually reduce headcount, and claiming it will damages your credibility. It reduces cycle time, which converts to faster revenue recognition on the sales side and faster vendor onboarding on the procurement side. It reduces rework, which is real time recovered. And it converts an audit exposure from a real risk into a non-issue. Those three are defensible. Efficiency percentages taken from a vendor deck are not.
If you want to map your current routing before evaluating anything, the document workflow generator walks through the steps and surfaces where the handoffs leak. The features page covers how HERO handles structured routing, and pricing is public if you are building a comparison.
Map what actually happens, not what the policy says. Sit with the people who route documents today and trace three real recent examples. The undocumented steps you find are the ones that will break your implementation if you miss them.
Start with one high-volume, low-complexity document type. NDAs are the canonical choice: frequent, standard, low risk, and everyone feels the improvement. Build credibility there before touching the complicated agreements.
Do not automate a bad process. If four approvals are genuinely unnecessary, remove them before encoding them. Automating an over-controlled process makes it faster to be over-controlled and much harder to fix later, because now it is in a system.
Run parallel for one cycle. Keep the old path available while the new one runs. Fully cutting over on day one means your first bug becomes an emergency.
Publish the cycle time. Making before-and-after visible is what converts the project from an IT rollout into something the business asks to extend to the next document type.
Document routing is specifically about moving a document through a sequence of reviewers and approvers with recorded outcomes. Workflow automation is the broader category covering any multi-step business process, most of which are not document-centric. Routing is a subset. The distinction matters when buying, because general workflow platforms often handle routing adequately while missing document-specific requirements such as version binding on approval, redline handling, and structural cross-reference integrity. If your process is fundamentally about documents, buy for that rather than buying a general automation platform and hoping.
Probably yes, because they solve different problems. E-signature handles execution, meaning the final step where parties bind themselves. Routing handles everything before that: internal review, approval, and the negotiation cycle. Most e-signature tools include a basic sequential signing order, which is routing for the signature step only. If your pain is that internal approvals take nine days before anything reaches signature, e-signature does not address it. If your pain is only the signing step, you may not need a separate routing tool.
For a single well-understood document type with a straightforward approval path, a few weeks is realistic including testing. For a full rollout across multiple document types with conditional logic and integrations into existing systems, plan in months rather than weeks. The variable that most affects the timeline is not the software but how clearly your current process is understood. Teams that have never mapped their actual approval paths spend most of the project discovering them, which is valuable work but should be budgeted honestly rather than discovered mid-implementation.
This varies by tool and it is worth asking explicitly. Some systems complete in-flight documents under the old definition and apply the new one to anything started afterward, which is the safest behavior. Others apply changes immediately to everything in progress, which can strand documents at steps that no longer exist or invalidate approvals already collected. Neither is wrong in principle, but you need to know which one you are buying, because the second requires you to time workflow changes around quiet periods.
Most tools support it in some form, typically through a link that does not require a full account. The questions to press on are what the external party can see, whether their actions appear in the same audit trail as internal ones, and what happens to their access after the document completes. Some implementations put external participation in a separate system with a separate trail, which means reconstructing the full history requires stitching two logs together. That is workable but you should know it before an audit rather than during one.
Parallel wherever the reviewers are genuinely independent, sequential only where one reviewer needs another's output. Most organizations default to sequential because email is inherently sequential, not because the dependencies require it. Auditing your current path for false dependencies is usually the cheapest available cycle time improvement, and it often turns out that two of three approvals could have run concurrently the whole time. Where genuine dependencies exist, keep them, because parallelizing a real dependency just produces approvals on stale information.
The correct behavior depends on what changed. A typo fix should not invalidate prior approvals. A change to the liability cap absolutely should. The best implementations let you define which sections are material, invalidating relevant approvals when those change while leaving others intact. Failing that, a configurable partial restart, where the workflow returns to a specified step rather than the beginning, is the workable compromise. Tools offering only "restart everything" or "continue silently" force you to choose between slow and unsafe, and you should know which one you are getting before purchase.
HERO is a document editor built for structured business documents, which means routing operates on a document whose sections, cross-references, and defined terms are real structural objects. Approvals bind to versions, material changes are detectable because the system knows what a material section is, and the document does not fragment into copies as it moves. If your routing problem is really a document integrity problem wearing a workflow costume, that is what we built for. Book a demo.