Watch a tech work a single ticket and count the tools. The PSA to read the ticket. The RMM to check the device. QuickBooks to see if the client's current on their invoices. The phone system to call them back. A security console to confirm the alert that triggered all of it was real. Five tabs, five logins, five different ways of naming the same company — for one ticket.
None of those jumps feels expensive. That's exactly why the bill never shows up anywhere. But it's real, it compounds across every ticket every tech works every day, and it's almost certainly the largest unmeasured cost in your shop.
What context-switching actually costs
The research here is older than the MSP industry and it's brutal. Gloria Mark's attention research at UC Irvine famously found it takes an average of about 23 minutes to fully re-focus after an interruption. The American Psychological Association's work on task-switching found that flipping between tasks can cost up to 40% of someone's productive time. And recent analyses of workplace telemetry put the average knowledge worker at ~1,200 application switches per day — roughly four hours a week just toggling and re-orienting.
Most of that research is about big interruptions — the meeting, the Slack ping, the fire drill. But the small switches add up too, and an MSP tech lives in small switches. Every hop from the PSA to the RMM is a tiny tax: find the right tab, wait for it to load, re-find the company (which is "Acme Corp" here and "Acme Corporation" there and a numeric ID somewhere else), re-build the mental picture, do the ten seconds of actual work, hop back. The work was ten seconds. The tax was sixty.
Let's put conservative numbers on it. Say a tech does 30 of these tool-to-tool hops a day, and each one costs a genuinely modest 90 seconds of find-load-reorient overhead. That's 45 minutes a day, per tech, spent navigating between tools rather than doing the work. Across a 5-tech shop that's almost four hours a day — half a full-time technician — evaporating into tab-switching. At a loaded labor cost of $50–75/hour, you're looking at $50,000–75,000 a year in pure overhead that produces nothing billable.
That estimate is deliberately gentle. It ignores the errors that creep in when someone copies an invoice number across windows by hand, and the context that quietly drops on the floor every time a tech gets pulled away mid-hop.
Why MSPs have it worse than almost anyone
A typical knowledge worker juggles their inbox, a chat app, and a couple of line-of-business tools. An MSP tech is structurally worse off, for three reasons.
- The tools are deep, not shallow. A PSA, an RMM, an accounting system, and a security platform are each a full application with its own navigation, its own search, and its own learning curve. Switching between them isn't like flipping browser tabs — it's like switching jobs every few minutes.
- The same client wears five different names. NinjaOne knows them by org ID, Freshdesk by company name, QuickBooks by a customer record that finance set up three years ago, 3CX by an extension range. Half the switching tax is just re-establishing "wait, which client am I even looking at" in each new tool.
- The work is interrupt-driven by design. Tickets, alerts, and phone calls arrive whenever they arrive. Every one of them yanks a tech out of whatever they were in and forces a fresh round of context loading. The job is, structurally, a context-switching machine.
So research that pegs the average worker at a few hours a week lost to switching almost certainly understates the cost for your techs. They're not flipping between a doc and an inbox — they're switching between five enterprise platforms, dozens of times a day, while getting interrupted.
The trap: solving a context problem with more tools
The instinct, once you feel this pain, is to buy something. A better PSA. An "all-in-one" platform. Another integration that promises to sync everything. We went down this road ourselves at the MSP we run, IT Pro Source, and learned the hard way that most of these "solutions" make the switching problem worse, not better.
An all-in-one PSA asks you to rip out the RMM, the accounting system, and the phone platform your team already knows and migrate years of data into one vendor's walled garden — a brutal, risky project that trades five good tools for one mediocre one. A new integration usually just adds a sixth tab. Every fresh platform is one more login and one more way of naming clients.
The deeper point is that your tools aren't the problem. Your RMM — NinjaOne, Datto, or whatever you run — is a great RMM. Your accounting system, whether that's QuickBooks, Xero, or Sage, does the accounting your accountant trusts. Your phone system runs your phones fine. The problem isn't any individual tool — it's the seams between them, and the tax your techs pay every time they cross one. You don't fix seams by buying more tools that have their own seams.
The fix: one read-only view over the tools you already have
What actually kills the context-switching tax is a single pane of glass that reads from your existing stack and shows a tech everything about one client in one place — without making them sign into five consoles to assemble it. When we built Morton Command Center, this was the entire premise: don't replace anybody's tools, just collapse the seams between them.
The architecture that makes this honest is a set of vendor-agnostic adapters. Morton Command Center sits on top of your existing stack and normalizes each vendor's data into one consistent model, so "Acme Corp" in one system and "Acme Corporation" in another resolve to a single company page. The product's own modules — ticketing, contacts and companies, the call log, timecards, devices, backups, security, procurement, revenue, invoicing, client billing, the customizable dashboard, and the customer portal — come ready out of the box. The connections to your tools are where the platform earns its keep: every integration is custom-built for your stack as part of your engagement. That is the advantage over rigid all-in-one suites that force you onto their pre-built integrations: because every connector is API-driven, your RMM (NinjaOne, Datto, or whatever you run), your accounting system (QuickBooks, Xero, Sage), your PSA, and your phone system all connect the same way. If your tool has an API, we build the integration for it — fit to your exact workflows. Nothing gets ripped out, and no data gets migrated — cancel tomorrow and your tools are exactly where you left them.
Concretely, here's what stops the hopping. Open one company page and you see their open tickets, device health, security posture, backup status, A/R balance, and contacts together. The dashboard is a customizable tile grid — each tech reorders, resizes, and adds tiles from a widget library to match how they actually work. Where an action belongs, it happens right there: click-to-call a contact through your phone system, reboot or push patches to a device through your RMM, create an invoice in your accounting system, reply to a ticket — through whichever vendor we integrate for your stack. Because each connector is API-driven and built to fit, the equivalent tool in any of those categories drives the same actions. The data is cron-warmed and refreshed within minutes, so the view is current without you opening a single vendor console to check.
A fair caveat: most of what you're surfacing is read-only by design, and that's the point. Morton Command Center isn't trying to replace the system of record — it's one place to see across all of them, plus the handful of write actions (call, reboot, patch, invoice, reply) those vendors actually expose. On security specifically, it surfaces and triages alerts and relays approve/reject/resolve actions back to your EDR (any security tool with an API gets its own integration built to your stack); it doesn't isolate or quarantine anything itself — that stays the security vendor's job. The goal is fewer tabs, not a new place to do everything.
How to measure your own switching tax
You don't have to take the research on faith. Run a five-minute audit this week. Pick one tech, watch them work three tickets end to end, and tally every time they switch tools. Note what they were looking for in each one — nine times out of ten it's a status, a number, or a name they're carrying from the previous tab. Multiply the count by your loaded hourly rate and a conservative per-switch overhead. The number is usually big enough to change the conversation.
Then ask the harder question: of those switches, how many were to do something versus just to look something up? The look-ups are the pure tax — that's the work a unified read-only view eliminates outright. If you'd like to go deeper on the economics of consolidating that layer without giving up your tools, we wrote about it in why MSPs end up paying 4× their headcount in platform fees, and laid out the broader case on our MSP efficiency and consolidate your MSP stack pages.
The tools aren't going anywhere, and they shouldn't. But the seams between them are costing you a technician you didn't know you were paying for. That's the part you can fix.