How CrystalCommerce kept scarce inventory accurate across sales channels
No baseline was captured on this engagement.
Optional analytics and marketing cookies stay off unless you allow them. Cookie policy · Privacy policy
Most automation business cases are one multiplication: hours saved times hourly rate. That number is always large and almost always wrong. Here is the arithmetic we actually use, including the two terms that usually get left out.
Try it
Three numbers get you the order of magnitude. Then we validate it against the real workflow and replace the estimates with measurements.
Three numbers. Everything is an estimate until we measure the real workflow - this is the arithmetic, not a promise.
Across the whole team, not per person. Between 5 and 2,000.
Time a real sample, including the awkward ones. Estimates run low. Between 1 and 180.
Salary plus taxes, benefits and overhead - roughly 1.3× base pay. Between 15 and 200.
We plan against 60% on a first workflow. Anything above 80% assumes very stable inputs, so treat it as the optimistic end.
What this process costs today
$7,404/month
195 hours of work a month, or $88,852 a year.
Estimated capacity value if 60% is removed
$53,311/year
About 117 hours a month - roughly 0.7 full-time equivalents of capacity handed back to the team.
This is capacity, not cash. It becomes money when it absorbs growth you would otherwise hire for, clears a backlog that is costing you revenue, or moves experienced people onto work only they can do. We will not call it guaranteed savings, because it isn’t.
We validate this against the actual workflow and send back the real numbers.
The arithmetic
If a vendor’s business case does not contain all eight of these, ask which ones they left out and why.
| Term | How we calculate it | The usual mistake |
|---|---|---|
| Current workflow cost | Monthly volume × minutes per item ÷ 60 × loaded hourly cost, plus rework and the cost of errors where we can observe them. Every term below is a monthly figure so they can be compared. | Using base salary instead of loaded cost, and timing only the straightforward items. |
| Residual manual cost | The share that will still need a person after automation, at a longer handling time, because the leftovers are the awkward ones. A monthly figure, like the one above. | Assuming this is zero. No automation of unstructured input reaches 100%, and pretending otherwise turns a success into a failure. |
| Build cost | The one agreed price for the workflow, quoted after the free initial audit and approved before delivery begins. | Leaving your own side out of the sum. The audit costs nothing, but the access, the sample and the decisions it needs are your team’s time, and mapping the process properly is most of why the build works. |
| Ongoing operating cost | Infrastructure and model usage, maintenance, and improvement work if you want the system to keep getting better. Not the exception queue - that is the residual manual cost above, and counting it in both places subtracts the same hours twice. | Forgetting maintenance. Vendors change APIs and models change behaviour whether or not you budgeted for it. |
| Capacity recovered | Hours removed from the process, expressed as capacity - and named as capacity, not as cash. | Calling it savings. It only becomes money through one of three specific mechanisms. |
| Error reduction | Fewer items requiring rework, and fewer downstream consequences: wrong shipments, credit notes, disputes. | Ignoring it, which usually understates the case more than the labour maths overstates it. |
| Revenue impact | Only where it is measurable: faster quotes, faster invoicing, shorter customer wait times. | Claiming a revenue number nobody can trace back to the workflow. |
| Payback period | Build cost ÷ (current − residual − run) using the monthly figures, which gives the answer in months. Divide annual figures by twelve first, or the number comes out in years. | Comparing build cost against gross hours saved, which is how automation projects get approved and then disappoint. |
For the complete formula and the signals that decide it before the arithmetic does, read how to calculate whether an AI automation is worth building.
Being straight about it
Removing 400 hours of manual work a month does not reduce payroll by 400 hours unless you actually reduce headcount, and most of our clients have no intention of doing that. What you get is capacity - which turns into money in exactly three ways.
01
The most common and the most defensible: the next 20% of volume arrives without the next two hires. This is the one we usually build the case on.
02
Quotes going out late, invoices going out slowly, customers waiting. Here the recovered capacity is directly traceable to money.
03
Real, and the one most people feel most strongly. Also the hardest to put a number on, so we do not lead with it.
We say estimated capacity value, not guaranteed savings. If a vendor tells you the second thing, ask which of those three mechanisms turns their number into cash.
After launch
Most of the gain in an automation is not on launch day. It is in the weeks afterwards, when the exception rate gets worked down and the thresholds get tuned against real data.
The system goes live beside the manual process, not instead of it, and the first real numbers arrive.
The first weeks surface the cases the map missed. Each one is either handled or routed to a person deliberately.
Confidence thresholds set from sample data get re-set from production data, which is usually where the second half of the gain is.
A rising exception rate almost always means something upstream changed. It is treated as an incident rather than as a curiosity.
Questions
Not automatically, and we will not pretend otherwise. Removing 400 hours of manual work a month gives you 400 hours of capacity. It becomes money when that capacity absorbs growth you would otherwise have hired for, or when it stops a backlog costing you revenue. We call it estimated capacity value, not guaranteed savings.
Monthly volume times minutes per item, divided by sixty to turn those minutes into hours, times the loaded hourly cost of the people doing it - plus the cost of rework and errors where we can observe it. We measure a real sample rather than accepting an estimate, because estimates of one’s own process are almost always wrong in the same direction.
Three things: infrastructure and model usage, which is usually small and metered; maintenance, because vendors change APIs and models change behaviour; and improvement work, if you want the system to keep getting better. We quote these separately so you can see what is fixed and what is variable.
The test we apply is whether the build repays inside a year on a workflow whose rules are stable. If it needs three years of perfect operation to break even, the assumptions will not survive that long. For low-volume or judgement-heavy work the answer is often that it never pays back - which is exactly why we measure before building instead of after.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
Send us the process. We measure a real sample, replace the estimates with numbers, and tell you honestly whether it is worth building.