Why model review load at all?
Because a Digital FTE proposes and a human decides, so every unit of work it produces creates a decision for somebody. Teams that hire one without planning for that decision load discover it in the second week, when the Approvals tab has more items in it than anyone has time to read. The load is not a flaw in the model; it is the mechanism that keeps a human accountable, and it has a size that can be estimated before hiring rather than discovered afterwards.
Modelling it also settles an argument that otherwise runs on feelings: whether the role is saving time overall.
The three inputs: volume, minutes per item, reviewers
Volume is the number of items the role proposes in a week, which follows directly from its remit and its schedules. Minutes per item is how long one review takes, which depends almost entirely on how much evidence arrives with the item. Reviewers is the number of people who can approve that class of work, which is usually one and occasionally two. Those three are enough; adding more inputs produces a more impressive model and not a more accurate one.
All three are observable in the workspace after a fortnight, so the initial estimate is replaced with measurement quickly.
The arithmetic: one week, with the inputs left blank
Weekly load in minutes is volume [V] multiplied by minutes per item [M]. Divided by reviewers [R], it gives minutes per reviewer per week. As an illustration with assumed inputs: a role proposing twenty items a week, each taking four minutes to review, with one reviewer, produces eighty minutes a week of review work — a little over quarter of an hour a day. The same role with items that take twelve minutes each produces four hours a week, which is a different decision entirely.
The multiplication is trivial and the point is not the sum. The point is that minutes per item is the term with the widest range, and it is the term most within a manager's control.
Why does evidence decide minutes per item?
A review is fast when the reviewer can see the claim, the source behind it, and what the role proposes to do, without opening another system. It is slow when the reviewer has to reconstruct the context: find the original ticket, check the figure, work out which version this is. The ftes.ai Approvals surface exists to collapse that reconstruction — each item arrives with its evidence, its verdict, and its audit trail attached — because the difference between a four-minute and a twelve-minute review is almost entirely reconstruction time.
The management implication is direct: a role whose reviews are slow usually needs better evidence per item, not fewer items.
How does autonomy change the model?
Autonomy reduces volume for one task class at a time. When a class is promoted, its items stop arriving for per-item approval and run within written bounds, still logged and still reversible, which removes that class from the weekly multiplication while leaving it in the audit trail. A role with one promoted class and three unpromoted ones has a smaller load than it had, not no load. The manager's work shifts from approving items to reading the record for that class at the monthly review.
This is why autonomy on ftes.ai is granted per class rather than per role. Promoting the whole role would empty the Approvals tab and hide the classes that still need reading.
What does an unacceptable load mean?
It means the role is misconfigured, and it is usually one of three things: a remit so broad that it proposes work nobody asked for, a schedule running more often than the underlying thing changes, or items arriving without the evidence that would make them quick. Each has a fix inside the workspace. The conclusion that a Digital FTE is unsuitable for the function should come last, after the remit, the cadence and the evidence have all been tightened and the load is still too high.
A useful test at the end of a fortnight: compare measured review minutes against the time the role's output would have taken to produce by hand. If review exceeds production, something is configured wrongly.
What the model leaves out: setup, corrections, investigations
It leaves out the value of the reviews themselves, which is where a manager transfers judgement to the role and where the send-back reasons come from. It also leaves out the irregular time spent on setup, on memory corrections, and on the occasional item that turns into a real investigation. Those are genuine and they do not fit a multiplication, so ftes.ai does not fold them into one. The model estimates the routine load, which is the part that repeats every week and therefore the part worth planning.
Read the estimate as a floor on the manager's time, not as the total.