Last quarter, workflows on Tessel asked people for 1.4 million approvals. The median response came in four minutes. The slowest one percent took longer than six hours, and almost all of those had the same cause: the request went to one person, and that person was busy, asleep or on holiday. I run finance at Tessel on Tessel, and this is the guide I wish I had when we built our own close.
Where a person belongs
Not every step needs a human. Putting approvals everywhere trains people to click yes without reading, which is worse than no approval at all. We put a person in the loop when a step is hard to undo, when it moves money above a threshold, or when it touches something an auditor will ask about.
Irreversible actions such as posting a journal entry to a closed period, issuing a refund or deleting a vendor record.
Threshold breaches where an agent has found a variance above the rule, like the 2 percent limit Halden uses for invoice matching.
First runs of a new workflow version, for the first day or the first hundred runs, whichever comes first.
Everything else should run on its own and leave a trace. If you are unsure, start with an approval and remove it once the trace shows you have never said no.
Choosing the approver
Name a role, not a person, wherever you can. A rule that sends refunds to "finance-oncall" survives holidays, reorganisations and resignations. A rule that sends them to one email address becomes a quiet single point of failure.
The approver should also be someone who can judge the request from the message alone. In Slack, a Tessel approval shows the amount, the agent's explanation and a link to the trace. If the approver needs to open three other systems to decide, the step is in the wrong place or the message is missing context.
Picking a backup
Every approval step in Tessel has a backup, and we recommend choosing it with care rather than defaulting to a manager. A good backup has the same authority as the primary, works in a different time zone or on a different schedule, and has agreed to be the backup. That last point sounds obvious. In our own setup, it was the one we skipped.
How long a run should wait
The escalation window decides how long a run waits before the request moves to the backup. Shorter is not always better. If the window is too short, backups get flooded with requests the primary would have answered a minute later.
Our rule of thumb: start at three times your median response time, then adjust using the traces. With a four-minute median, 15 minutes is a reasonable start. For payments with a cut-off, or anything a customer is waiting for, 30 minutes is the most we would accept.
The Friday evening invoice
In March, a supplier invoice for 48,000 euros arrived at 18:40 on a Friday. Our rule sent it to me, with a backup in Lisbon and a 30-minute window. I was on a train with no signal. After 30 minutes the request moved to the backup, who approved it at 19:22, and the payment went out before the bank's weekend cut-off. Before Tessel, that invoice would have sat in a shared inbox until Monday and cost us a late fee.
An approval nobody answers is just a slower way to fail.
Write the rule down
Approval rules are part of the workflow, so they are versioned, reviewed and replayed like any other block. Ours looks like this:
The last line matters. If neither person answers, the run holds and tells the channel, rather than approving or failing on its own.
If you want to see how the request looks on the approver's side, the Slack integration page walks through it step by step.
PH
Pieter Hendriks
Head of Finance
Pieter runs finance at Tessel, including the month-end close and supplier payments that run on Tessel itself. Before joining he was a controller at a Rotterdam freight forwarder, where approvals lived in a shared mailbox and nobody knew the backup.