An approval by email leaves no process behind: it leaves a conversation. Nobody knows for certain where it stands, who is holding it up, or on what basis it was decided. Automating approvals means turning that conversation into a flow with rules, deadlines and a record.
What follows: why email fails as an approval mechanism, what automates well, what still requires judgement, and what changes with electronic signature.
Approvals sit inside every important process: a purchase, a contract, an off-policy discount, an access grant, a payment. And in most organisations they are settled by email.
That works until someone asks how long a request has been stalled, who actually approved it, or why an exception was authorised. At that point email stops being enough.
Why email fails as a mechanism
It has no state. A message does not know whether the request is pending, approved or expired, so the state lives in the head of whoever is chasing it.
It has no deadline. Nothing happens when an approval has sat still for eight days, unless someone remembers to chase again.
It has no rule. If the amount requires two signatures, nothing stops it advancing with one. The control depends on people remembering the policy, not on the system applying it.
And it leaves no usable evidence. Reconstructing an approval chain from forwarded emails, months later, with people who have since left, is exactly what turns an audit into a problem.
What automates well
Rule-based routing. Who must approve according to amount, type of spend, area or risk. It is a deterministic decision: the same input always produces the same path, which is why it is the best candidate.
Deadlines and escalation. A request that exceeds its time escalates to the next level or notifies an owner. This is the change that shortens cycles most, because it attacks the real cause of delay, which is rarely the decision itself.
Pre-checks. Confirming the request carries what it needs — available budget, attached documents, third-party details — before it occupies an approver’s time. Returning what is incomplete early avoids the back-and-forth.
Delegation during absence. An approver on holiday should not stall a process. Recording the delegation with a validity period and letting it operate on its own is straightforward, and it avoids the practice of sharing credentials, which is how this gets solved when no mechanism exists.
What requires judgement
The approval policy itself. How many levels, at what thresholds, and who may authorise an exception are governance decisions, not technology ones. Automating a badly designed policy applies it faster and with less discussion, which is the opposite of the goal.
Exceptions also need an explicit home. A flow that only contemplates the happy path forces people out of the system when a legitimate but different case appears, and from then on the record stops reflecting reality.
And the underlying decision stays human. Automating the flow does not mean automating the judgement of whether something is advisable: it means whoever decides receives the complete case, on time and with context.
What changes with electronic signature
Approving and signing are not the same thing. An approval is an internal control step; a signature is a declaration of intent with legal effect, and the bar is different.
Colombia and Mexico both recognise electronic signature, at different levels depending on the mechanism used and the traceability accompanying it. The practical rule is that the greater the consequence of the document, the higher the level of signature required and the more solid the evidence of identity.
Which level corresponds to which type of document is a definition worth settling with the legal team before building the flow, not after. It is the kind of requirement that forces a redesign when it arrives late.
How to sequence the project
Pick a process with known volume and known pain — low-value purchasing is usually the best first — and model its real path, including the exceptions currently settled outside the system.
Instrument before optimising: if you do not know how long each step takes today, you will not be able to demonstrate the improvement or identify where the delay sits.
Then extend to neighbouring processes reusing the same flow engine. The common mistake is building a different flow per area, leaving the organisation with five approval mechanisms and no standard.
What has to exist first
A current approval policy with an owner. A reliable directory of people and roles, because routing depends on knowing who holds which position today. And an explicit decision about which documents require a signature, and of what kind.
With those, the flow is construction. Without them, it is a governance discussion dressed as a technology project.
Which process is best to start with?
One with high volume and moderate consequence, such as low-value purchasing. It delivers a visible result early and allows the design to be refined without serious cost.
Are approving and signing the same thing?
No. Approval is an internal control; an electronic signature is a declaration of intent with legal effect. Which documents require a signature, and at what level, is worth defining with the legal team before building the flow.
What shortens cycle times most?
Deadlines with automatic escalation. Most of the delay is not in deciding but in the request waiting without anyone noticing.
How are exceptions handled?
By giving them an explicit path inside the flow, with a defined approver and a record of the reason. If the system only contemplates the normal case, people settle it outside and the record stops being useful.
