Approval workflow: how to design one people don't route around

An approval workflow is the path a document takes from "someone wrote it" to "the company stands behind it". It exists because a few decisions are expensive to get wrong: a contract with an indemnity clause nobody read, a price list published a digit short, a policy that contradicts the employment agreements. Most documents do not need one. The ones that do need a workflow short enough that people use it instead of walking down the corridor.

The failure mode is always the same. A workflow is designed for the worst case — five approvers, sequential, everything routed — and within a month the urgent work quietly goes around it. Then you have neither speed nor control, plus a system of record that no longer records anything.

What an approval workflow has to specify

• Which documents enter it. Named categories — customer contracts, anything with a payment term, public copy, HR policy — not "important documents".
• The threshold. Below it, one owner decides; above it, the workflow runs. A number makes the rule enforceable in a way that judgement does not.
• Who approves what, by role rather than by name, so holidays don't stall the queue.
• Sequential or parallel. Legal and finance rarely need to see a draft in order; send it to both at once.
• A deadline per step, and what happens when it passes — escalate, or treat silence as consent for low-risk categories.
• What approval attaches to: a specific version, not "the document". Approving a moving target is how altered drafts get signed.
• Where the record lives afterwards, so an auditor or a successor can reconstruct who agreed to what.

Write down the escape hatch too. There will be a Friday afternoon when the deal closes or it doesn't, and the CFO is on a plane. A named fallback approver and a rule that the exception is logged afterwards beats the alternative, which is people inventing an escape hatch you never see.

Designing the steps

1. List the documents that actually caused a problem in the last two years. That list, not an org chart, is the scope.
2. For each, name the one risk an approver is checking for — commercial terms, legal exposure, factual accuracy, brand. An approver without a stated question rubber-stamps.
3. Assign one approver per risk. Two people checking the same thing means neither checks it.
4. Set the threshold so that the majority of documents skip the workflow entirely. If more than a fifth of your documents need approval, the threshold is wrong.
5. Give each step a working-day deadline and a stated consequence for silence.
6. Freeze the version on submission. Changes after approval restart the step — no exceptions, because this is the rule that makes the record worth keeping.
7. Publish the whole thing on one page and put a link to it wherever documents are created.

Approval, review and sign-off are not the same thing

Review is advisory: comments you may accept or refuse. Approval is a decision by someone accountable for a stated risk. Sign-off — a signature — is the legal act that binds a party. Teams that collapse these into one step end up asking a lawyer to fix typography, or asking a designer to accept liability. Keep them in order: review first, approval next, signature last, and only signature needs to be a signature.

The practical version of this in Ettex: draft and review happen in Ettex Docs, where comments are threaded and resolvable and version history means you can point at the exact draft an approver saw. Approval itself is a decision recorded against that version — a resolved comment thread from the accountable person, or a status you move once. When the document has to bind someone, it goes to Ettex Signature for a real signature with an audit trail. Intake for the requests that start the whole thing fits Ettex Forms, whose submissions land in one searchable, timestamped inbox rather than in somebody's mail.

Ettex has no rules engine that routes a document automatically between named approvers, and this article does not pretend otherwise. What it gives you is the substrate an approval workflow needs — versioned drafts, threaded comments, a signature with an audit trail, a shared inbox for requests. For a team of a few dozen that is usually enough; if you need conditional routing across hundreds of documents a month, you want dedicated workflow software.

Where approval workflows go wrong

• Too many approvers, chosen politically. Each additional approver adds delay and subtracts a sense of responsibility from the others.
• Sequential routing where parallel would do, which turns four one-day reviews into a four-day wait.
• No deadline, so "waiting on legal" becomes a permanent state that nobody owns.
• Approval by email, where the approved version is an attachment that has since been edited twice.
• A threshold set so low that everything is exceptional, which is the same as having no workflow.
• No record. Six months later the question is not whether it was approved but who approved it and on what basis, and nobody can say.

Measuring whether it works

Two numbers are enough. Median time from submission to final approval tells you whether the workflow is tolerable; the share of documents that bypassed it tells you whether it is real. If the first is under three days and the second is near zero, leave it alone. If bypass is high, the answer is almost never enforcement — it is that the workflow costs more than the risk it manages, and the threshold or the approver list needs cutting.

A good approval workflow is small, fast and honest about the few documents that need it. Set the threshold high, name one approver per risk, freeze the version, and record the decision where the document lives — everything else is procedure for its own sake.