Quantifying soft costs: how to put a number on time-to-decision
Operations leaders who have tried to get automation funded know the specific frustration of being asked to quantify benefits that are real but hard to express in dollars. Labour hour savings are straightforward: take the time saved per transaction, multiply by volume, multiply by hourly loaded cost. But decision lag, the time a process loses while a decision is pending, is harder to pin down. It is a soft cost: real, measurable in the workflow data, but diffuse in its financial impact.
Finance teams are not unreasonable when they push back on soft costs. The problem is not that they do not believe the costs are real. The problem is that they have seen too many business cases where a claimed time saving did not translate to any actual financial change. If you want decision lag to count in your business case, you need to be able to trace it to a financial outcome that finance can verify after the fact.
Here is how to do that, specifically for time-to-decision in approval and review workflows.
What time-to-decision actually measures
Time-to-decision is the elapsed time between when a decision request enters a queue and when a decision is rendered. In approval workflows, this is the gap between "submitted for approval" and "approval granted or denied." In review workflows, it is the gap between "sent for review" and "review complete."
It is distinct from the time the decision-maker spends on the decision. A senior manager might spend twelve minutes reviewing and approving a proposal, but if that proposal sat in their queue for six days before they opened it, the time-to-decision is six days plus twelve minutes. The twelve-minute active portion often accounts for less than 5% of the total.
This distinction matters because it changes the intervention logic. A twelve-minute decision does not benefit from an AI decision-assistant. A six-day queue wait benefits from prioritisation automation, escalation rules, or queue balancing. The improvement is in the mechanics around the decision, not in the decision itself.
Three methods for attaching dollar values
There is no single correct method for quantifying decision lag costs. The right method depends on what downstream effects the lag actually has in your organisation. Here are the three most defensible approaches.
Method 1: Downstream project delay cost
If the decision is gating a downstream project or transaction, the cost of decision lag is the cost of the delay it causes. A staffing request approval that takes six days instead of one delays a project start by five days. If that project has a daily run rate of $8,000 in billable activity, the five-day delay costs $40,000 in delayed revenue recognition, or in delayed value delivery if the project is internal.
This method requires you to trace a specific type of decision to a specific downstream effect, and to have data that links decision lag duration to project start delay. The workflow event data from your project management and approval systems usually contains this. The calculation is then a median analysis: what is the median decision lag for this type of approval, what is the corresponding downstream delay, and what is the daily financial value of the downstream activity? Multiply and annualise.
Finance teams respond well to this method because it connects the soft cost to a financial outcome they can independently verify. If you say "our staffing approvals take a median of six days, which delays project starts by an average of four days, and each delayed project start costs an average of $32,000 in delayed revenue recognition," finance can check the project data and validate the claim.
Method 2: Holding cost of in-process inventory
In processes involving financial commitments, goods, or contracts, decision lag creates a holding cost: the value tied up in an in-process item that cannot be moved forward until the decision is made. A purchase order pending approval is a commitment of working capital that cannot be managed until the approval is granted. A contract pending legal review is a revenue opportunity that cannot be closed.
The holding cost method calculates the average value of items sitting in a decision queue multiplied by the cost of capital and multiplied by the average queue time. For a purchase order queue with an average pending value of $340,000, an average queue time of 5 days, and a cost of capital of 8%, the annual holding cost of the queue delay is approximately $37,000. This is a conservative calculation that even a sceptical CFO will recognise as standard financial analysis.
Method 3: Labour opportunity cost from coordination overhead
Decision lag creates coordination overhead in the teams that are waiting for the decision. When a work item is pending approval, the people whose work depends on that approval are either blocked, spending time tracking status, or context-switching to other work and incurring re-entry costs when they return. This overhead is measurable if you can estimate the average number of follow-up interactions per delayed decision and the loaded cost per interaction.
A reasonable estimate for an approval process with a 4-day average queue time: 1.5 status check interactions per pending item (email, Slack message, or call), each costing 15 minutes of the requestor's time. At $85 per hour loaded cost for a mid-level ops professional, that is $32 per delayed decision in coordination overhead alone. Multiplied by 2,000 decisions per year, that is $64,000 in pure coordination cost that adds no value to the process.
This method is less dramatic than the project delay method, but it has the advantage of being calculable from data you almost certainly have: transaction volume, average queue time, and loaded cost by role.
Building the composite figure
In most cases, a credible business case for reducing decision lag uses a combination of methods, each covering a different financial impact category. The structure looks like this:
Downstream delay cost: [calculated from method 1, supported by project data]. Coordination overhead: [calculated from method 3, supported by transaction and role data]. Optionally, holding cost: [calculated from method 2, if financial instruments are involved]. Total annual cost of current decision lag: [sum]. Conservative improvement target: [what you expect to achieve, with stated assumptions].
The conservative improvement target is important. A claim that you will eliminate decision lag entirely is not credible. A claim that you will reduce median approval time from 6 days to 1.5 days (based on a parallel pilot or comparable implementation data) is defensible. The improvement estimate should be grounded in either data from a pilot or in a specific analysis of what is causing the current lag and how the proposed change addresses it.
What this method cannot do
The dollar quantification of decision lag is not the same thing as the dollar value of faster decisions. Faster decisions produce competitive advantages, improved relationships, and organisational agility that are real and valuable but largely impossible to quantify in a budget proposal. We are not saying these benefits do not exist. We are saying they do not belong in a finance-facing business case unless you can trace a specific causal chain to a measurable financial outcome.
The discipline of this framework is in limiting claims to what can be defended. Soft cost quantification gets a bad reputation in budget processes because practitioners include speculative benefits that they cannot support. If you include only what you can measure and trace, the number will be smaller but it will be credible. Credible numbers get approved. Optimistic numbers get questioned until the meeting runs out of time and the project gets deferred.
Time-to-decision is a real cost. It can be measured. It can be translated into financial terms that survive a CFO's scrutiny. What it requires is workflow data to establish the current baseline, and a clear causal chain from lag to financial impact. Both of those are achievable with the data most operations teams already have access to.