Approvals and routing
Every request reaches the right person with what they need to decide, and waits there until they sign off.
A routing system for requests that need a sign-off: an expense, a discount, a document release, a change to a client record. It sends each one to the right approver with the context attached, records the decision and carries it out.
No list price. It starts with a diagnostic at a fixed fee, and the build is quoted after it.
How it works
The pipeline, step by step.
- 01
A request is raised
From a form, an email, a chat message or another system.
- 02
The request is classified
What is being asked, for how much, by whom, under which policy.
- 03
The approver is chosen
By your rules: role, amount, department, client. With a backup when someone is away.
- 04
The context is attached
The request, the relevant policy, the history and the figures the approver needs.
- 05
The decision is made
The approver signs off, asks a question or rejects, from email, chat or a one-page view.
- 06
The action is carried out
The record is updated, the payment released or the document sent, and the requester is told.
- 07
The log is kept
Who asked, who decided, when and why.
Connects to tools such as
- Slack
- Microsoft Teams
- Gmail
- Outlook
- QuickBooks
- Xero
These are examples. We confirm the method for each of your tools before we build.
Where a person approves
The points where the system stops and waits for a person.
- A person makes every decision. The system routes and records; it does not approve.
- Routing rules and thresholds are set by you and changed only on your instruction.
- Anything the rules do not cover goes to a named default approver.
How it is measured
Named measures, scored on your own files before launch and after every change.
- Routing accuracy: requests sent to the correct approver, checked against the rules on a sample.
- Completeness: whether the approver had the context they needed, measured by follow-up questions.
- Time waiting for a decision, as an operating measure.
How it is run
After launch: monitoring, updates and what you own.
- Monitoring on every request: unrouted requests, missed backups and failed actions raise an alert.
- Rule changes are tested on past requests before release.
- Handover: a runbook, a data map and code owned by the business.
What it will not do
Limits we set on purpose.
- It does not approve anything on its own, at any amount.
- It does not change a routing rule because a requester asks.
- It does not carry out an action the approver did not sign.
Sectors we build for
The business types this system is built for.
Questions
Where do approvers see requests?
Where they already work: email, chat or a one-page view. The decision is recorded the same way whichever they use.
What if the approver is away?
Your rules name a backup. After the delay you set, the request goes to them, and the log shows it.
Can it approve small routine requests itself?
No. Every decision is made by a person. This system exists to route decisions, not to make them.
What is in the audit log?
Who raised the request, who was chosen and why, what they saw, what they decided, when, and what action followed.
Talk to us about approvals and routing
Fifteen minutes on a call is enough to tell whether it fits your work. If it does not, we say so.