Every company is a two-tool company now, and support is what breaks in the seam

Someone in finance asked me how many laptops we owned. I said I would get back to her by end of day.

It took two days.

The data existed. It existed four separate times, in four separate places, and no two of them agreed within eight percent. One console knew about everything with a Windows license. Another knew about everything Apple had ever shipped us. The procurement spreadsheet knew what we had paid for, which is a different question than what we have. And the security agent's dashboard knew about a set of machines that overlapped the other three imperfectly, including sixty-odd devices nobody else had heard of.

I gave her a number with a range attached and hoped nobody would ask me to defend the range.

That afternoon is the whole argument here. Not the sprawl. The two days.

The baseline, stated plainly

Ask around and you will find that essentially every organization manages more than one device platform, and most manage three or more. Windows and Apple, then Linux somewhere in engineering, then a pile of Android handsets in the field that arrived without anyone signing a form.

Most of those same organizations run two or more separate management tools, each with its own independent endpoint agent, purely to cover the platform mix.

I have stopped calling this a planning failure. It is the ordinary operating condition of an IT department now, arrived at honestly by thousands of teams making individually defensible decisions. Somebody bundled device management into a license you already owned, and somebody else needed a tool that genuinely understood Apple. Nobody was wrong on the day they signed the contract.

The bill arrives in a boring form: multiple sources of truth. You cannot say how many devices you have. You cannot say how many software licenses are outstanding, or how many people actually use the product you renew every January, not without a human manually stitching exports together and then defending the seams to somebody who has never opened either console.

The cost that never makes it into the business case

I have written a consolidation business case. It had licensing savings in it, and a paragraph about reduced attack surface, and a slide about administrative overhead measured in hours per week. All of it was defensible and none of it was the real number.

New IT hires walk into a multi-tool estate and face a genuinely complicated workflow just to get their bearings on how the place is arranged. Which console owns Macs. Which one owns compliance. Which one lies. Which one is authoritative for the thing they were asked about at 9:15 on their fourth day.

That complexity does not stay inside the IT department. It transfers straight to the person waiting on a ticket, as minutes and then hours of resolution time, and nobody logs it as a tooling cost because it shows up in a completely different report.

Tool sprawl is a ticket-resolution-time problem long before it is an architecture problem. If you only pitch consolidation on license math, you are pitching the small half.

20,000 against 500,000

One major cross-platform vendor runs something like 20,000 Macs internally against roughly 500,000 Windows PCs. Their own product manager, talking about their internal IT organization, said plainly that it "does not manage Macs very well." He also said that most customers adopting the platform for Mac are doing so because senior leadership said they had to.

I have a lot of respect for saying that out loud. It is also the single most useful fact in this entire discussion, because it tells you exactly where the engineering attention goes in a vendor with a 25-to-1 internal ratio.

The consequence on the ground is a dual-agent estate. Admins describe running a second endpoint agent purely to get faster local script and install execution than the primary management channel allows, while the primary tool keeps handling compliance reporting. Even fleets that completed their migration end up dual-agent by necessity rather than by choice, and the vendor confirms the pattern: people commonly keep an agent from another tool around.

So the promise was one console with one agent. What plenty of teams got was one console with two agents and a slightly better story to tell the board.

One platform manager put the reliability problem in terms I have not been able to shake. Asked whether slow and unreliable reporting from the management agent was just something to live with, his answer was: "I don't think as a platform manager I can turn to my cybersecurity team and say, that's just the way it is. I just don't think that's acceptable." He also said, about the tool he had been mandated to adopt, that he was not confident he could tell leadership it met his organization's criteria.

That is what mandated consolidation feels like from underneath.

What the unification pitch actually buys you

I want to state the counter-argument properly, because it is stronger than the skeptics allow.

A single console with identical navigation, identical terminology, and identical workflows across Windows, Mac, Linux, iOS, and Android mainly reduces the training burden on support technicians. That is the honest claim. Someone with a Windows background gets into the console and solves a Mac problem without being an expert in Mac. Someone who came up on mobile can look at a Linux box and find the same tab in the same place.

The tradeoff is real and vendors mostly admit it. Platform-specific terminology gets flattened for the sake of consistency, so a supervised device becomes a "company owned" device and an unsupervised one becomes "personally owned." Purists find that imprecise, and they are technically correct.

For years I was one of those purists. I argued that flattening the vocabulary trained technicians to think sloppily about platforms that are genuinely different underneath, and I lost that argument slowly, over about three years of watching cross-trained people resolve tickets they had no business being able to resolve. Precision in the console has a cost. So does making every Mac question wait for one of the two people who speak Mac. The second cost was bigger in every environment I have actually worked in.

Three carriers, because the city has neighborhoods

Device management is not the only place your estate is mixed. One city and county government IT organization runs AT&T, Verizon, and T-Mobile simultaneously, because coverage genuinely varies by which part of the city a department operates in. Public safety in one district needs one carrier. A health clinic across town needs another.

The relationships are not equivalent either. Their words: their AT&T rep is great, while their T-Mobile rep is "just happy to be in the room where it happens." Anyone who has managed vendors will recognize both of those people.

You cannot consolidate that away. The physical world is mixed, so some of your tooling stays mixed, and pretending otherwise just means the third carrier gets managed by nobody.

The easiest money you will find this quarter

After that same organization finished its migration, license reconciliation turned up something almost funny. They were paying for roughly 4,000 device licenses against about 3,500 actual active devices. Five hundred phantom devices, billed faithfully, for years.

They now run a weekly zero-use device report and a separate weekly "hasn't checked in" report from the carrier, reviewed monthly, and use both to go challenge departments on whether they still need the paid lines they are holding.

I bring this up because it costs nothing. No migration, no procurement cycle, no architecture review. Two scheduled reports and one uncomfortable monthly conversation, and it recovers real money in an environment where you already know your inventory disagrees with itself.

Where the pane of glass cracks

Unattended access does not flatten. Full background access without a user present exists on Windows. It does not exist on Mac or iOS, for platform reasons that are not going away. Your remote-support playbook cannot be uniform even when your console looks uniform, and the technician who learned the Windows path will hit a wall on their first Mac callout.

Policy targeting has a waiting room. Dynamic group evaluation can take anywhere from minutes to more than 24 hours depending on your org size and rule complexity. That leaves a live gap between "device enrolled" and "device policy-correct," which lands precisely when a new hire most needs their machine to just work. If you have ever had a first-day user tell you the Wi-Fi profile never showed up, that gap is where they were standing.

Policy visibility is solvable, and mostly unsolved. The best answer I have seen is a strict parent, child, grandchild hierarchy where common configuration lives at the top and only true exceptions get overridden further down, with visible inherited-versus-overridden indicators. It lets an admin look at one device and see at a glance where its applied policy diverges from the organizational default. That question is embarrassingly hard to answer quickly in most tooling, and it is the question you get asked during every incident.

Regulated tenants live on a different calendar. Feature rollouts do not reach government-cloud and regulated tenants on the same timeline as commercial ones, and there is no reliable public source to track that lag. You find out by asking your account rep and getting a verbal answer, which is a wonderful thing to build a project plan around.

My actual answer

Consolidate. I am not going to hedge on that.

But consolidate for the training burden and the single record, not for the org chart or the license line. Get one console your technicians can navigate half-asleep, get one inventory that finance can quote without a two-day stitching exercise, and accept that you will probably keep a second agent around for the jobs your primary channel executes too slowly. Make dual-agent a documented, budgeted decision you take once, rather than a secret each admin keeps to themselves.

And write down the capability gaps before you promise anyone a uniform experience. The console flattens. The platforms do not.

The thing I keep coming back to is how much of this cost is invisible by construction. Nobody bills you for the hour a technician spent deciding which tool to trust. It shows up as a ticket that took a day instead of an afternoon, and a new hire who was still uncertain in month four, and a finance partner who has learned that the answer to a simple question is "let me check."

Every company is a two-tool company now. Your inventory can still be one number.

---

Foqal gives IT teams one support surface across the chat tools their colleagues already use, so a mixed estate does not have to mean a mixed front door.