Perceived Lost Time in IT Support: A Difficult Conversation Worth Having

For IT support providers, perceived lost time is not always an easy subject to raise with customers.

If the number is low, a customer might question the value of their agreement.

They may think:

“Are we paying a lot for support we hardly use?”

If the number is high, the opposite concern appears.

They may think:

“We are paying for support, but look how much time our staff are still losing?”

That makes lost time a sensitive measure. It needs to be handled carefully.

The aim should never be to simply present a number and leave the customer to interpret it on their own. That would be risky and, in some cases, unfair.

Perceived lost time needs context.

It needs explanation.

Most importantly, it needs to be linked to action.

The purpose should not be to blame the customer, the provider, or the service desk. The purpose should be to understand where time is being consumed, why people feel time is being lost, and what can be done to reduce the impact.

One practical way to start measuring perceived lost time is through the CSAT survey process.

After a ticket is closed, the customer is already being asked how they felt about the service they received. This creates a natural opportunity to ask one additional question:

“How much time do you feel was lost because of this issue?”

It will not be perfectly accurate, and it does not need to be.

The value is not in pretending the number is exact. The value is in understanding the customer’s view of the impact.

That perception matters.

If a customer logs an issue and receives an excellent service, they may record the lost time as low. Even if the issue itself was inconvenient, a quick response, clear communication and good ownership can reduce how much time they feel was lost.

On the other hand, if the customer had to chase, repeat themselves, wait for updates, or deal with the same issue more than once, they may feel that more time was lost.

That tells the provider something that ticket data alone may not show.

Two customers could experience similar issues but feel very differently about the time lost. One may feel the impact was low because they were supported quickly and clearly. Another may feel the impact was much higher because they had to work around the problem for longer than expected.

That does not make the measure useless.

It makes it human.

A ticket can be resolved within target, but the customer may still feel that the issue cost them too much time. Equally, a ticket may take longer because the issue is complex, but the customer may still feel supported if the communication and ownership were strong.

This is why perceived lost time should sit alongside CSAT, not replace it.

CSAT tells us how the customer felt about the service.

Perceived lost time helps us understand how much the issue affected their working day.

Used together, they give a better view of both the experience and the impact.

The uncomfortable truth is that wasted time exists whether it is measured or not.

If staff are repeatedly waiting for systems to load, dealing with the same application issues, chasing updates, restarting devices, repeating information, or working around unresolved problems, that time is already being lost.

Not measuring it does not protect the customer.

It simply means the customer and provider may not have the evidence needed to make better decisions.

This is where perceived lost time can become useful.

Used properly, it can help move conversations away from opinion and towards evidence.

Instead of saying:

“We think this needs attention.”

A provider can say:

“Your team is telling us that time is being lost in this area. We can also see repeated tickets linked to the same issue. Based on that, we think this should be prioritised.”

That is a much stronger conversation.

It is not just about what the provider thinks.

It is about what the customer is experiencing.

It is important to be fair.

Not every interaction with IT is wasted time.

Some time is necessary and valuable. Onboarding new starters, improving security, completing planned changes, supporting projects, training users, replacing old equipment, and improving systems all take time.

That does not mean the time is being wasted.

The real focus should be on avoidable lost time.

This could include:

That is where the value sits.

The question is not:

“How much time did the customer spend with IT?”

The better question is:

“How much time does the customer feel was lost unnecessarily, and what can we do about it?”

One of the strongest reasons to measure perceived lost time is that it can help customers prioritise their IT roadmap.

Every business has limited time, budget and attention. Not every IT recommendation can be approved immediately. Not every project will feel urgent. Some improvements may sit on a roadmap for months because they are seen as useful, but not essential.

Perceived lost time can change that conversation.

If a particular system, server, application or process is repeatedly causing staff to feel they are losing time, that gives the customer evidence to bring the related project forward.

For example, a provider may have previously recommended patching a server, updating third-party applications, replacing older hardware or improving a manual process. At the time, the recommendation may have been noted but not treated as urgent.

Then, over time, staff begin experiencing delays. Applications become unreliable. Tickets increase. People start feeling that time is being lost.

Perceived lost-time data can help connect those issues back to the original recommendation.

The conversation changes from:

“We recommend doing this because it is best practice.”

To:

“We are seeing that this issue is now affecting your team’s time. Based on the impact they are reporting, this may need to move higher up your IT roadmap.”

That is much more meaningful.

It helps the customer understand not just what needs doing, but why it matters now.

It also helps ensure that projects are prioritised based on the impact on their people, not just technical preference or the loudest complaint.

Used well, perceived lost time gives customers a clearer view of which IT improvements will make the biggest difference to their teams.

Service reviews often focus on ticket volumes, SLA performance, open actions, customer satisfaction and upcoming projects.

Those things matter.

But perceived lost time could add a different layer to the conversation.

It could help answer questions such as:

Where do your people feel they are losing the most time?

Which issues keep coming back?

Which systems are creating the most disruption?

Which departments are most affected?

Which recommendations now have stronger evidence behind them?

Which roadmap projects should be brought forward because they are affecting teams the most?

This is where perceived lost time becomes more than a number.

It becomes a way of helping the customer make better decisions.

A service review should not just tell the customer what happened last month. It should help them understand what needs attention next.

Perceived lost time can help do that.

Customers want to feel that their provider has their best interests at heart.

That means being honest about what is happening, but also careful about how the message is framed.

Perceived lost time should not be used as a scare tactic. It should not be used to force a sale. It should not be used to make the customer feel responsible for every issue.

Handled badly, it could damage trust.

Handled well, it could strengthen it.

A good lost-time conversation might sound like this:

“We have reviewed the areas where your team feels the most time is being lost. Some of this is linked to repeat issues, some is linked to older systems, and some could potentially be reduced through automation or process improvement. We would like to talk through the options with you and agree what would make the biggest difference.”

That feels very different from simply saying:

“Your staff lost 40 hours because of IT issues.”

The first approach is collaborative.

The second approach feels like blame.

The difference is the narrative.

Perceived lost time should also be interpreted fairly.

It should not automatically be treated as a failure by the service desk or the provider.

Sometimes time is lost because a customer-side decision is delayed. Sometimes a third party is involved. Sometimes a recommendation has been made before but not approved. Sometimes the cause sits with an ageing system, a known risk, a training gap, or a process that needs to change.

There is also a difference between the actual time spent fixing an issue and the time the customer feels was lost because of the impact on their day.

Both matter, but they are not always the same.

That is why the number should never be left to speak for itself.

It needs a clear explanation of what happened, what caused the delay, what has already been done, and what options are available.

Perceived lost time should help identify ownership.

It should help clarify whether the answer is better communication, faster escalation, a technical fix, a project, user training, automation, or a decision from the customer.

That is when the measure becomes useful.

AI and automation are making this area much easier to explore.

Service providers now have more opportunity to review ticket data, spot repeat issues, summarise common themes, identify delays, and understand where manual work is taking longer than it should.

This can help both the provider and the customer.

AI can help highlight where the same issue keeps appearing. Automation can reduce repetitive tasks. Better reporting can show where time is being consumed. Smarter workflows can help prevent avoidable delays.

But AI is only useful if we ask the right questions.

The question should not simply be:

“What can we automate?”

It should be:

“Where are people telling us they are losing time, and would automation help reduce it?”

That distinction matters.

There is little value in automating a poor process if the real issue is unclear ownership, outdated systems, missing training, or a recommendation that has already been made but not acted upon.

The value comes from understanding the cause first, then deciding what should change.

Perceived lost time will never be a perfect measure.

It will need judgement. It will need context. It will need careful explanation.

Some time will be estimated. Some impact will be difficult to quantify. Some issues will involve several causes, not one simple answer.

That does not mean the measure has no value.

Many useful service measures are imperfect. Customer satisfaction, NPS, ticket priority, call quality and complaint themes all require interpretation. Perceived lost time is no different.

The important thing is to use it responsibly.

It should support better decisions, not create fear.

It should help customers explain where their people feel delayed, not make them feel exposed.

It should help providers evidence recommendations, not hide behind technical language.

It should be treated as a guide, not a verdict.

Perceived lost time is a sensitive topic, but that may be exactly why it is worth discussing.

If service providers want to move beyond basic reporting, they need to be willing to talk about the real impact IT issues have on people and businesses.

If customers want better value from their IT support, they need to understand where time is being consumed and which improvements would make the biggest difference.

The opportunity is not just to measure perceived lost time.

The opportunity is to use that information to have better conversations.

Where do staff feel time is being lost?

What keeps happening again?

Which recommendations now have stronger evidence behind them?

What could be automated?

What needs investment?

Which roadmap projects should be brought forward because they are affecting teams the most?

For me, this is where the conversation becomes interesting.

Perceived lost time is not about proving failure. It is about understanding where people feel they are being pulled away from their real work and using that insight to make better decisions.

The challenge is not only whether we measure it.

The challenge is whether we are ready to talk about it in a way that builds trust.

So perhaps the real question is not whether perceived lost time should be measured.

It is whether service providers and customers are ready to talk about it openly enough to use it well.

If you are a service provider, would you feel confident bringing perceived lost time into a customer review?

And if you are a customer, would this help you make better decisions about your IT roadmap?