Redeployed salaries need a second benefit calculation

I would give an automation credit for freeing people to do better work. I would not count their continuing salaries as cash saved and then count all of their new output again.

Vercel says its lead-qualification agent helps one SDR do the work of ten. SaaStr's account with COO Jeanne DeWitt Grosser reports about $5,000 annually in infrastructure and tokens, maintenance using 20 percent of an engineer and a claimed 32x ROI. It also says the people moved into higher-value roles.

That combination describes a potentially valuable redesign of work. It does not supply a complete, independently verified return calculation. Runtime spend is one cost category, and redeployment is a different benefit mechanism from removing payroll expense.

The distinction is worth preserving because a strong operational story should not need a weak financial shortcut to earn support.

Capacity can be valuable without becoming cash

Imagine a hypothetical team spending most of its week qualifying incoming leads. An agent takes over a bounded part of that process, and the team moves time into developing existing accounts.

The company still pays those employees. The first measurable benefit is capacity released from the original workflow. The next question is what happened to that capacity: did it reduce a backlog, avoid additional hiring, improve coverage or produce incremental contribution in the new role?

Those outcomes have different evidence. Avoided hiring needs a credible counterfactual about the roles that otherwise would have been filled. Incremental sales contribution needs a reasonable attribution method. A smaller backlog can matter before it has a precise monetary value.

I would keep the uncertainty visible instead of pricing every freed hour at a salary rate and calling the result realised savings. That estimate can describe opportunity, but it should remain labelled as an estimate of capacity value.

The opposite mistake is assigning redeployment no value because headcount stayed flat. That would reward layoffs over useful organisational improvement. The answer is a more accurate benefit record, not a narrower imagination about what automation can achieve.

Put the operating work in the denominator

The cost side needs the same care. Build time, subject-matter review, monitoring, maintenance and incident handling can sit in existing salaries while still consuming scarce capacity. A low infrastructure bill does not make those activities free.

For an investment review, I would show the initial build separately from recurring operation, use a defined time horizon and preserve the baseline workload. Then record realised cash changes, avoided costs and additional business output in separate lines so the same benefit cannot quietly appear twice.

Quality belongs beside the calculation. Faster qualification is useful only if the resulting decisions meet the business's acceptance standard. A process that needs more downstream correction may move labour instead of releasing it.

I have not audited Vercel's internal calculation and would not infer its full economics from the public account. The lesson I would take into my own review is to make the bridge from operational change to financial value explicit.

A capacity story can be impressive on its own terms. Let it earn a cash claim only when the cash actually moves.

Count redeployment as capacity first, measure what that capacity produces next, and keep continuing payroll out of the cash-savings line.