A shorter task does not automatically create an equivalent amount of usable capacity. The saved minutes may be scattered across a day, accompanied by new checking work or concentrated among people whose workload differs from the population used in the investment proposal. In insurance technology, I think the CIO should make those conditions visible before a programme turns a timing result into a staffing commitment. The operating function then has a real choice about how work will change.
The attraction of the simpler calculation is understandable. A task occurs many times, a tool makes it faster, and multiplication produces a large annual number. The arithmetic can be correct while the management conclusion remains unsupported. It may assume that every user experiences the same reduction, that no new task appears and that all the released time can be scheduled into something else. Those assumptions deserve evidence, especially when the proposed consequence is a permanent reduction in a team's capacity.
Observe the additional work as carefully as the reduction
At Caldermere, a claims assistant reduced the time colleagues spent composing material but introduced a deliberate verification step. We wanted the reviewer to inspect relevant sources and change unsuitable wording. A benefit model that measured only drafting would therefore reward the programme for excluding part of the process we had intentionally designed. I asked for an observed work study that separated preparation, checking and the subsequent activities of the claims colleague.
The six-week exercise covered sixty adjusters. We observed an average forty-two minutes a day released from drafting and eighteen minutes added through verification. The resulting twenty-four minutes were useful evidence about that cohort and period. They were not a measured benefit for every claims role in the insurer. The group was not a random sample of all work, and other operating conditions could have influenced the comparison. I wanted those qualifications on the same page as the result.
The checking time was not necessarily a defect to remove. Some of it represented the review required to make the tool useful within its authorised scope. Other parts might reflect avoidable navigation or repeated retrieval of the same document. The next design question was which was which. An engineering team could improve the latter without pretending that professional verification had become unnecessary. That is a more informative conversation than treating every minute added after automation as resistance from users.
Observation also needs respect for the colleague doing the work. If people believe a diary is being used solely to justify reducing their team, they may reasonably question the purpose and reliability of the exercise. We explained what would be measured, kept the limitations visible and involved claims management in interpreting the findings. The study cost USD160,000 including measurement and training. I regarded that expenditure as part of understanding the investment, rather than a nuisance outside the programme's financial account.
Ask who can use the time, and when
Twenty-four minutes spread through a working day are different from a continuous twenty-four-minute appointment. A colleague may finish one preparation task earlier but still be waiting for a customer to return a call or for specialist input. Another may have a queue of suitable work ready immediately. The practical value depends on scheduling, case mix, authority and the next task. Technology cannot settle those questions by multiplying the cohort average by the entire headcount.
Our claims leader assigned fifteen of the observed twenty-four minutes to proactive customer follow-up. The remaining nine were left unallocated while supervisors examined how unevenly the benefit was distributed. That was an operating decision, not an admission that the remaining time had no value. It acknowledged that the organisation had not yet established a reliable way to use it. The staffing plan remained unchanged. We could then examine whether the intended follow-up actually occurred without counting a payroll reduction in advance.
The owner of that decision should be named. A programme manager may assemble the benefit case, but the manager who controls the work must decide what activity will be added, reduced or stopped. Finance needs to understand when a benefit would affect expenditure and when it would instead improve service or absorb demand. The CIO should ensure the evidence is available and the technical change can support the proposed use. None of those roles is replaced by a model that produces a convenient staff-equivalent total.
Different uses can be legitimate. An insurer might choose to improve communication, reduce overtime, handle a growing queue or release capacity for training. Each choice needs an appropriate measure and an honest account of cost. They should not all be described as the same financial saving. Better customer follow-up can be worthwhile even where it does not reduce the payroll. A board can judge that proposition if management presents it plainly rather than disguising it as a benefit of another kind.
Let the business case retain its uncertainty
I would separate observed results, proposed operating changes and future assumptions in the approval paper. The first describes what happened in a defined setting. The second states what management intends to do with the change. The third identifies conditions that remain to be established. Keeping these categories distinct makes later review more useful. If the expected benefit does not appear, the organisation can ask whether the technology performed differently, the operating change was not made or an assumption proved unsuitable.
The comparison design also deserves attention before the pilot begins. Our study helped challenge an unsupported staffing claim, but it did not isolate every cause of a change in working time. A future exercise could use a more carefully chosen comparison group and record case complexity more consistently. That would improve the evidence without requiring the original study to claim an experimental certainty it did not possess. The strength of the conclusion should follow the strength of the design.
I ask teams to revisit the result after the novelty of the tool has passed. Early users may invest extra effort in learning or receive more support than later users. Conversely, initial enthusiasm can conceal work that becomes burdensome at scale. The continuing review should include quality, rework and the tasks supervisors actually assign. A timing result from the launch period is one observation in that account, not a permanent entitlement to remove a fixed quantity of capacity every year.
There is no need to make the investment argument timid. A well-supported change can produce meaningful value, and some changes will eventually support a different staffing model. The requirement is to show the steps between faster activity and that consequence. I want a programme to succeed because the insurer can explain how work improved, who made the operating decision and what evidence supports the benefit. An attractive multiplication should begin that enquiry, not bring it to an end.