TL;DR: Before building, we calculate hours saved times fully-loaded hourly rate times working days, subtract the system cost, and get a payback period. If it doesn't pay off, we don't build.
Why we start with numbers, not technology
Software without business context is a cost, not an asset. So every engagement starts with the financial logic that justifies it — not a list of tools we could use.
The framework in three steps
- 1. Measure the real cost of the process. How many hours a week it takes, who does it, and the fully-loaded rate (salary plus overhead). Many underestimate because they count only salary.
- 2. Estimate the achievable saving. It's rarely 100%. A realistic target is to eliminate 40-80% of the manual work, with a human left for exceptions.
- 3. Compare against the system cost. Setup fee plus monthly maintenance versus the annual saving gives a payback period — usually months, not years.
A worked example
A process that takes 20 hours a week, at a fully-loaded rate of 15 KM and a 70% saving, frees up about 14 hours a week. That's over 700 hours a year — value that almost always exceeds the cost of building.
FAQ
What if we don't know exactly how many hours the process takes?
That's common. In the discovery phase we map the process together and reach a realistic estimate before any commitment.
Can you calculate this for us?
Yes — our free assessment gives a prioritized list of automations with a savings estimate for your specific process.