The savings model: rate, realisation factor and minutes per run

How ProcessTwin turns an agent run into pounds — and how to make the number your finance team will defend.

Updated Aug 2, 2026

Every projected saving is a simple, transparent calculation:

minutes recovered per run × hourly rate × realisation factor

You set all three at Settings → Savings model, and every ledger entry records the exact derivation it used — so nothing is a black box.

The three levers

  1. Hourly rate — the blended, fully-loaded cost of the person whose time an agent gives back. One tenant-wide default; keep it honest (salary + on-costs ÷ working hours).
  2. Minutes recovered per run — how long the task took a human, per agent type (invoice, support, email, and so on). Edit these to match the customer's reality.
  3. Realisation factor — the honest haircut. It's the fraction of freed time that actually converts into reclaimed capacity. A finance director will never accept 100% ("you didn't really get all that time back"), so setting it to, say, 70% is what makes the number credible. It applies to projected savings only.

Why this matters

The whole product is about proving ROI, so the maths has to survive scrutiny. Because every assumption is visible and editable — and written onto each ledger row — a customer can audit and adjust it rather than take it on faith. That is the difference between a number a CFO waves away and one they sign.

Live preview

The Savings model page shows the £-per-run for each agent type as you edit, so you can see the impact of a change before you save it.

Was this article helpful?

Related articles