Approvals almost always run on email first, and email works for longer than people expect. It stops working in a recognisable way: nobody can say which requests are waiting, the person who approved something cannot be identified two months later, and the same request gets approved twice by two people who could not see each other's replies. At that point somebody starts looking at approval workflow software, and the shortlist fills up with products whose demos are indistinguishable. The useful work is not comparing feature lists. It is five checks, four of which the demo will not volunteer.
What actually breaks in email approvals
Worth being precise about the failure, because the wrong diagnosis leads to the wrong category of product.
The routing is rarely the problem. In most organizations everybody already knows who approves what, and when they do not, asking takes thirty seconds. What email genuinely cannot do is hold state. There is no list of what is outstanding, because the outstanding items are scattered across individual mailboxes. There is no owner, because a message sent to three people belongs to none of them. There is no history, because the record is a thread that can be deleted, and the version in the approver's mailbox may differ from the version in the requester's. There is no status the requester can check, so they ask, and the asking is most of the volume.
That list points at something narrower than a workflow engine. A shared place where each request has one owner, a stage, a history and a reply, solves all four. Conditional routing solves none of them. This is why teams sometimes buy a routing engine, configure it faithfully and find that the chasing continues: the chasing was never about who decides.
The corollary is that the check for any candidate product is not whether it can express the approval rules. It is whether, on any given morning, one screen shows what is waiting, for how long, and whose move it is.
The licence question decides the cost
Pricing models in this category differ in kind, not just in amount, and the unit being charged for determines whether a tool is cheap or expensive for a particular shape of team. Published figures, checked today.
| Priced by | Example | Published price | Gets expensive when |
|---|---|---|---|
| Each person who acts | Power Automate Premium | $15.00 per user per month paid yearly | Many occasional approvers |
| Unattended automation | Power Automate Process | $150.00 per bot per month | Several parallel unattended runs |
| Monthly submissions | Jotform | Starter free with 100 submissions and 5 forms, Bronze $39, Silver $49, Gold $129 per month | Request volume grows |
| Seats and records | Airtable | Free with 1,000 records per base, Team $20 per seat per month billed annually | Both headcount and history grow |
| Plan plus extra users | ProcureDesk | Startup $830 per month billed annually, 10 users included, $20 per month each extra | Headcount grows past the bundle |
| Not published | Kissflow | Pricing page directs to a consultation | Unknown until a call |
The pattern to watch for is a tool priced by everybody who touches the process, used in a process where most participants touch it rarely. Forty managers who approve two things a quarter each are forty licences under a per user model and no extra cost at all under a model priced by request volume or by the small number of people who administer the process. Neither model is wrong. They suit different shapes.
The related question, and the one most often left until implementation, is whether an approver can act without holding a seat. Approving from a reply to an email, or from a button in a chat message, keeps the licence count to the people who run the process. That capability is worth asking about explicitly, because "supports email notifications" and "supports approving by email" are different claims and get described in similar words.
Conditional routing, and how much of it is real
Conditional routing is the headline feature and it is usually over specified. The classic shape is a threshold: below one figure a manager decides, above it finance is added, above another a director signs.
There is a cheap test for how much of this is needed. Take the last quarter of requests, apply the proposed rules on paper, and count how many would have been routed differently from what actually happened. A handful means the rules describe an exception, and an exception handled as a note on the intake queue costs nothing to run and nothing to change. A large proportion means the routing is doing real work and a tool that expresses it is worth paying for.
The hidden cost of routing is maintenance. A rule set encodes an organization chart, and organization charts change. Every reorganisation, every new cost centre, every departure requires somebody to go back into the tool and update the branches, and that somebody is usually one person who becomes the only one who understands the configuration. Before committing, it is worth asking who that will be and whether the rules can be edited by a non specialist.
There is also a design question worth settling early: parallel or sequential. Sending a request to three approvers at once is faster and produces ambiguity about whether all three or any one of them is required. Sending it in sequence is slower and unambiguous. Tools differ in which they support and in whether the distinction can be set per form. It is a small detail that generates a surprising amount of argument once the process is live.
Absence is the check most shortlists skip
Every approval process works until an approver is on leave. The difference between tools is what happens on day four.
Four mechanisms exist, and a candidate product should be asked about each by name. Delegation lets an approver nominate a substitute in advance. Reassignment lets an administrator move a waiting item to somebody else. Timeout moves or escalates an item automatically after a set period. Ageing visibility shows, on one screen, what has been waiting longest.
The last of these is the cheapest and the most underrated. A board sorted by how long each item has been sitting, looked at once a day by whoever owns intake, catches absence without any automation at all. It also catches the cases the other three miss, such as an approver who is present and simply has not got to it.
What deserves scepticism is a product that routes confidently and has none of the four. In that configuration a waiting request is formally assigned and practically invisible, which is worse than a shared mailbox, because at least a shared mailbox looks untended. If the answer in a demo is that this rarely happens, the honest translation is that it is not handled.
The audit trail, and what a trail has to include
Audit trail appears on every feature list in this category and covers a wide range of things. Three questions separate the useful from the nominal.
Does it record who, what and when for every state change, or only for the approval itself. A trail that captures the approval but not the two reassignments and the returned request before it does not explain how a decision was reached.
Can it be edited or deleted by the people it records. A history that a participant can quietly amend is a note, not a record. This is worth asking because in several general purpose tools the history lives in the same editable object as the data.
Does it include what was sent to the requester. Approvals generate messages, and a dispute about an approval is often a dispute about what somebody was told. A record that keeps the decision and the correspondence in the same timeline answers that in one place. This is the part where tools built for handling responses rather than automating flows tend to be stronger, since keeping the answers, the notes, the stage changes and the sent messages on one timeline per request is the shape of the product rather than an add on.
None of this requires a compliance obligation to be worthwhile. The everyday value is that a stalled request can be explained without anybody having to remember.
Where approvals should live
Three placements are on offer and each has a real cost.
In the inbox. Approving from an email is the lowest friction for the approver and the highest for everyone else, because the state ends up distributed across mailboxes again unless the tool writes it back to a central record. Acceptable when the tool keeps the record and the email is only the interface.
In the chat tool. Approving from a message in a team channel gets the fastest response times, for the same reason that anything in a chat tool gets attention. The failure mode is that channels scroll. An unanswered approval in a channel is gone by the afternoon, so this placement needs one of the absence mechanisms above behind it.
In a place of its own. A queue or a board that people open deliberately. Slower to get a response and much better at showing what is outstanding. This is the placement that actually fixes the four things email cannot do, and the usual mistake is choosing it and then not giving anyone the habit of opening it.
The combination that works in practice is a board as the record with notifications pushed into whatever tool the team already reads, so nobody has to remember to check and the state still lives in one place.
Running a trial that tells you something
Most trials of approval tools prove nothing, because they are run on invented requests by the person who is already convinced. A trial that produces an answer has three properties.
It runs on real requests, in parallel with the current process rather than instead of it. Duplicating the work for two weeks is annoying and it is the only way to compare like with like, because a trial on fabricated requests never hits the awkward cases that cause the actual delays.
It includes at least one approver who did not choose the tool and does not care about it. The question that matters is whether somebody who was not in the meeting can act on a request without being trained, and a trial staffed only by enthusiasts cannot answer it.
It measures two numbers, not a feeling: how long requests sat waiting, and how many messages were exchanged that were only about status. Both are countable from the current email process too, which is what makes the comparison possible. A tool that improves neither is not solving the stated problem, however much better it looks.
What to change first
Before shortlisting, apply the proposed routing rules to last quarter's requests on paper and count how many would have moved differently, because that number decides whether a routing engine is the purchase at all. If the real complaint is that nobody can see what is waiting, start with one queue where each request has an owner, a stage and a visible age, which is what Halict puts on screen without any rules to configure.
Q1. Is approval workflow software worth it for a small team?
It depends which problem is being solved. If the complaint is that nobody can see what is outstanding and the requester has to ask, a shared queue with an owner and a stage fixes that cheaply. If the approval rules themselves are genuinely conditional and change often, a tool that expresses those rules earns its cost.
Q2. How much does approval workflow software cost?
The models differ more than the numbers. Microsoft lists Power Automate Premium at $15.00 per user per month paid yearly and Power Automate Process at $150.00 per bot per month. Jotform prices by monthly submissions, with a free Starter plan at 100 submissions and paid plans from $39 to $129 per month. Airtable prices per seat from $20 per seat per month billed annually. Some vendors, including Kissflow, publish no prices and direct visitors to a consultation.
Q3. Can approvals be done by email without any software?
Yes, and for low volumes that is reasonable. What email cannot provide is a list of what is outstanding, a single owner per request, a history that participants cannot edit, and a status the requester can check without asking. When those four start costing real time, that is the signal to move, and it is a different signal from the routing being too complicated.
Q4. What happens to approvals when the approver is on holiday?
That depends entirely on which of four mechanisms the tool has: delegation set in advance, reassignment by an administrator, an automatic timeout or escalation, or simply a view showing what has been waiting longest. The last one is the cheapest and catches cases the others miss. A product that routes confidently but has none of the four should be treated with caution.
Q5. Do approvers need their own paid account?
In per user pricing models, usually yes, which is what makes those models expensive when there are many occasional approvers. Some tools let an approver act from an email reply or a chat message without holding a seat. It is worth asking about directly, since supporting email notifications and supporting approval by email are described in similar language and are not the same capability.