Vendor case studies love a big percentage. "40% faster," "60% cost reduction." Useful as a headline, not useful for deciding whether a project is worth it for your specific business. Here's the approach we actually use with clients before committing budget.
Start with hours, not percentages
Take the process you're considering automating and estimate the hours it currently costs per week, loaded with a realistic hourly cost (salary plus overhead, not just wage). That's your baseline. Multiply by 52 for an annual figure, and you have a real number to compare a project cost against — not a marketing claim.
Add the costs automation usually misses
Build cost is obvious. Two costs are easy to miss: ongoing maintenance (APIs change, edge cases appear) and the ramp-up period where a new workflow runs slower than the old one while your team adjusts. Budget for both, and the ROI estimate holds up better once the project is live.
What a realistic year-one payback looks like
For a well-scoped project — a specific, repeated, rules-based task — we typically see payback inside three to six months once the automation is live and stable, with the remainder of year one as clear net gain. Broader, less-defined projects take longer to pay back and carry more risk of scope creep.
The honest caveat
Automation compounds. The first project on a given workflow usually returns less than the second, because the second reuses infrastructure and lessons from the first. If you're evaluating a single, isolated project, be conservative. If you're evaluating a program of several related automations, the later ones tend to look a lot better than the first.