Key takeaways
- Automation should speed up the routine path and slow down the exceptional one. A system that treats both identically has not been designed, only installed.
- Route by entity, department, role level, compensation band, location and exception threshold — and always name a fallback approver.
- Keep the rule that applied and the decision that resulted in the same activity trail.
- Generate the final document only from approved data, and store the exact version the candidate responded to.
Define approval rules
Route by entity, department, role level, compensation band, location and exception threshold. Name a fallback approver, and define explicitly what happens when an approver is unavailable — this is the single most common cause of a stalled offer.
Rules should be readable by the people they govern. An approval matrix that only the system administrator can interpret produces the same escalation calls it was meant to eliminate.
| Dimension | Why it routes differently |
|---|---|
| Entity | Different signatories and policies per legal entity |
| Role level | Senior appointments warrant additional review |
| Compensation band | Offers above a threshold need a further approver |
| Location | Location-specific policy or wage considerations |
| Exception threshold | Any override of the approved requisition or band |
Separate routine and exception paths
An offer that sits within an approved requisition and band may reasonably follow a short path. A compensation override, a new clause or a senior designation should require additional review.
Keep both the rule that applied and the decision that resulted in the activity trail. Six months later, the question is rarely "was this approved" — it is "why did this particular offer take that path", and only the rule answers that.
| Routine path | Exception path |
|---|---|
| Within approved requisition and band | Compensation above the approved band |
| Standard template, no clause changes | Non-standard or newly added clause |
| Established role level | Senior or newly created designation |
| Single approver, short timeline | Additional approver, documented rationale |
Control the final document
Generate the PDF only from approved data. Where the document can be edited after approval, the approval covers something other than what the candidate receives — which defeats the purpose of having one.
Deliver through a secure link, record expiry and reminders, and store the exact accepted or declined version with timestamps.
- 01
Generate from approved data only
No manual edits to the document after approval. A change means a new approval.
- 02
Deliver through a secure link
Expiring and authenticated, not a public URL or an email attachment that can be forwarded indefinitely.
- 03
Track expiry and reminders
Automatic follow-up on pending offers, with the deadline visible to the candidate.
- 04
Store the exact response
The accepted or declined version with its timestamp, retained as issued rather than regenerated later.
Frequently asked questions
How many approvers should an offer need?
As few as the risk justifies. Most routine offers within an approved requisition and band need one. Additional approvers should be triggered by a defined condition — a compensation override, a senior designation, a non-standard clause — rather than applied to every offer by default.
What happens if an approver is unavailable?
This should be defined in advance, not resolved by phone each time. Name a fallback approver and a timeout behaviour, and record which of the two acted so the trail stays accurate.
Can an approved offer be edited before it is sent?
It should not be. If the document can change after approval, the approval no longer describes what the candidate receives. Route any change back through approval — with a well-designed routine path, that costs far less than the control it preserves.
This resource provides general HR operations information and is not legal, tax or regulatory advice. Requirements vary by organisation and employee circumstances.