Your team switches apps 1,200 times a day. Here's the bill

Nobody notices the twelfth time they switch tabs. That is exactly the problem.

A few years ago, researchers at Harvard Business Review partnered with a company called Soroco to measure something almost nobody tracks: not how long people spend inside each application, but how often they move between them. The answer came back at roughly 1,200 times a day. The people doing it had very little idea it was happening.

Here is what makes that number worth sitting with. Each individual switch is trivial, a second or two, barely a blip. The recovery is not. Your attention does not move as fast as your mouse does, and every time you jump from the CRM to your inbox to the scheduler and back again, there is a lag while your brain reloads what you were in the middle of. The research put that cost at around four hours a week per person, purely re-orienting. Not doing the work. Finding your way back to it.

Four hours a week is roughly nine percent of the working year. Call it five working weeks. Every person, every year, spent finding their place again.

The loss that never shows up anywhere

If your company lost five weeks of output to a system outage, there would be a post-mortem. Someone would own it. There would be a slide with a timeline on it.

This loss does not arrive as an event. It arrives as a Tuesday that felt relentlessly busy and produced nothing you can point to. It arrives as that flat, foggy feeling at 2pm that you put down to lunch, or sleep, or getting older. Nobody logs it, because there is nothing to log. There is no error message for "I lost the thread."

That is why tool sprawl is so difficult to argue about internally. The cost is real and measurable in aggregate, and completely invisible in the moment it happens.

A quick note on the maths, because it matters

You will often see the 1,200 figure quoted next to another statistic: that it takes about 23 minutes to fully refocus after an interruption. Multiply those two together and you get a number implying nobody has completed a piece of work since 2019.

So let us be straight about it. Not every toggle triggers a full 23-minute recovery. Most are shallow, a glance, a check, a copy and paste. The 23-minute figure comes from research into deeper interruptions, and it is genuinely useful for understanding why one badly timed message can flatten a whole morning. But the two numbers do not multiply. What they describe together is a spectrum: hundreds of small switches costing seconds each, and a handful of real ones costing half an hour.

The four-hour weekly figure already accounts for that mix. It is the conservative number. It is still five weeks a year.

Where the switches actually come from

Here is the uncomfortable part. Almost none of these switches happen because someone is distracted or badly organised. They happen because the work genuinely lives in different places.

A customer emails a question. Answering it properly means checking their history in one system, their contract in another, their open tickets in a third, and their last invoice in a fourth. That is four switches for one reply, and every one of them is necessary. The person doing it is not procrastinating. They are doing the job in exactly the shape the tools have arranged it.

The average employee now works across 11 to 13 applications daily, up from seven in 2022. That is not a behaviour change. That is an infrastructure change that happened around them, one reasonable purchase at a time.

The relay race problem

Think about a relay race. Four runners, one baton. Every runner is fast. But the team's time is not the sum of four fast runs, it is the sum of four fast runs plus three handovers, and handovers are where races get lost.

Business software has the same shape. Each tool is good at its own leg. The CRM is a perfectly good CRM. The scheduler schedules. But nobody owns the handover, and the handover is where context gets dropped, where a customer has to explain themselves twice, where the number in one report quietly disagrees with the number in another.

Adding a faster runner does not fix a dropped baton.

What to do with this on Monday

You do not need to fire anyone or buy anything to start here. Three things are worth doing.

Count properly first. Ask a few people to note, for one single day, how many separate applications they need to finish one ordinary task from start to end. Not how many they have logins for. How many one task actually requires. The answer is usually higher than anyone expects, and it is a far more honest number than any licence audit will give you.

Look for the repeated handovers. The switches worth fixing are not the random ones. They are the ones that happen every single time a certain kind of work comes through the door. Those are structural, and structural things can be redesigned.

Be sceptical of anything that adds a thirteenth app to fix the twelve you already have. If the proposed answer to fragmentation is one more destination, it is not really an answer.

The tools are not the problem. The distance between them is.