B2Shift · Published 27 August 2026 · Updated 27 August 2026
Most automation ROI numbers you'll see in a sales deck skip the assumptions that determine whether they're realistic. A defensible ROI model states its inputs explicitly, so you can challenge them.
Start with a real baseline, measured before building anything
Before you build, measure the current process: how long it takes per instance, how many instances per month, error or rework rate, and who currently does the work. Without this baseline, any "time saved" figure after launch is a guess dressed up as a measurement.
Model the honest cost side, not just the build cost
Total cost includes the build (a focused MVP starts around €2,500 at B2Shift), ongoing operations and monitoring (from €650 per month), and third-party platform fees — orchestration tools and connected systems have their own pricing that quoted automation prices frequently exclude. Skipping this side of the ledger is the single most common way ROI projections turn out optimistic.
Separate hard savings from soft benefits
Hard savings are countable: hours reclaimed at a defined hourly cost, error-driven rework avoided, faster response tied to a measurable conversion lift. Soft benefits — team morale, "strategic capability" — are real but should never carry the business case alone, because they can't be checked against reality six months later.
Account for adoption, not just capability
A workflow with 100% technical capability and 40% team adoption delivers 40% of the modelled return. Build the adoption assumption into the model explicitly, and revisit it at the post-launch review — this is usually where optimistic ROI projections actually fail, not in the technology.
Set a review point and compare against the baseline, not the pitch
Four to six weeks after launch, measure the same metrics you captured in the baseline, using the same method. Compare against that baseline, not against the number in the original proposal — the baseline is real, the proposal was a forecast. Use the ROI calculator for a first-pass model, then replace its default assumptions with your own measured numbers as soon as you have them.