The Next Generation Workplace Does Not Need Twenty SaaS Products

The case for consolidating the workplace is not a procurement case, it is a control case. Twenty products cost twenty invoices, and the invoices are the least interesting number on the page: the same estate also costs twenty trust boundaries, twenty audit surfaces and twenty copies of the organisation's data, and none of those three ever appears in a renewal negotiation. We should say the honest thing early, because the argument does not need dishonesty to work: best-of-breed genuinely wins on features, and it wins by a distance. A specialist whose entire existence depends on one category will out-feature a consolidated equivalent, and the people using it daily will notice. So the question is not whether a suite matches the specialist. The question is what an organisation is buying when it accepts a boundary, and whether it has ever priced that.

What is the real unit of cost in a workplace estate?

The unit is not the seat, it is the boundary. Every product in the estate is a point at which data changes custodian: a different legal entity holds it, under a different contract, with a different sub-processor list, a different retention default, a different jurisdiction of storage, a different breach notification path and a different definition of what counts as an incident. The seat price is negotiated once a year by procurement, competently and visibly. The boundary is never negotiated at all, because nobody in the room owns it.

The arithmetic is unkind. Products grow linearly and connections between them grow with the pairs: twenty products admit one hundred and ninety possible pairings, and while no estate wires all of them, the ones it does wire are precisely the ones carrying the most sensitive traffic, because that is where the work is. Each connection is a standing authorisation, not a one-off transfer. The scheduling assistant does not read the diary once, it holds a grant that reads the diary indefinitely, until somebody notices.

Why is a trust boundary more expensive than a licence?

Because a licence is a priced, bounded, annual liability, and a boundary is an unpriced, unbounded and effectively permanent one. The licence appears in the budget, and somebody signs it. The boundary appears in the data protection impact assessment, in the annual security questionnaire the vendor answers about itself, in the sub-processor changes a customer is told about rather than asked about, and eventually in an incident timeline. Nobody signs off on a trust boundary. It is acquired as a side effect of signing off on a feature. Features are consumed by individuals, per person, per task, with immediate and visible benefit. Boundaries are consumed by the institution, over years, and the cost is deferred and diffuse. That is not a criticism of the people choosing tools. It is a description of a governance model that prices one side of a trade and not the other.

What happens to the audit when the record lives in twenty places?

It stops being a record and becomes a reconstruction. Twenty products produce twenty log formats, twenty clocks with twenty degrees of drift, twenty retention windows set by twenty vendors' defaults, and twenty export procedures with twenty support queues behind them. When a regulator asks who approved a decision, on what data, using which system, at what time, the honest answer in most estates is that the organisation will assemble an answer afterwards from logs written to help engineers debug software, not to prove anything to anybody.

That distinction carries the whole argument. A log is written after the fact and describes what a system believes happened. A sealed record is written before the action and commits to what is about to happen. Under GDPR, an organisation making decisions with legal or similarly significant effects owes the person affected meaningful information about the logic involved, and Article 22 gives them the right to contest the outcome and obtain human intervention. Under NIS2 and DORA, incidents have to be reported inside timelines that assume the organisation already knows what occurred. An estate that discovers its own history by joining twenty exported files is not accountable in any meaningful sense. It is hopeful.

Is best-of-breed simply wrong?

No, and any argument that needs it to be wrong is a weak argument. Feature depth compounds with focus, and focus is exactly what a specialist has and a generalist does not. Users who prefer the specialist are usually right about the thing they are judging. The point is that they are judging a different balance sheet: the one measured in minutes saved per task, not the one measured in custodians, jurisdictions and evidence.

Consolidation has a failure mode of its own and it deserves to be named plainly. A suite can be a monoculture: one blast radius, one roadmap that does not care about your edge case, one renewal in which you have no leverage because leaving means leaving everything. Some suites earned their sceptical reception fairly, by bundling an adequate version of everything and calling it a strategy. So the case here is not that fewer vendors is better. It is narrower and it is testable: for the class of work that must be explainable to a regulator, a court or a board, the number of trust boundaries should be one, and the number of copies of the underlying data should be one.

Does AI strengthen the case for consolidation or weaken it?

It sharpens it, because AI converts a fragmentation problem into an authority problem. When every product ships its own assistant, the estate does not gain one AI capability, it gains twenty inference boundaries, each with its own answer to where the prompt went, what was retained, which jurisdiction held it for the seconds it existed, and who could compel its production. The step change is agents that act rather than suggest. An assistant that only reads poses a confidentiality question, and confidentiality questions can largely be managed with contracts. An agent that books, sends, approves, refunds, files or reconciles poses an authority question, and authority cannot be delegated to twenty vendors each holding a private opinion about what clearance means and when to escalate. Twenty agents, twenty sandboxes, twenty escalation models and twenty logs is not an AI strategy. It is twenty pilots wearing the same badge.

What would a consolidated workplace have to be to justify itself?

It would have to reduce the boundaries without cashing in the user experience, and it would have to be specific rather than rhetorical about what it offers. Five tests are enough.

• One identity and one clearance model: the same person with the same permissions across email, meetings, CRM, collaboration and knowledge, and one place to revoke them.
• One record: every consequential action sealed before it executes, hash-chained, and verifiable by an outsider who does not trust the system that produced it.
• One copy of the data: held on hardware the organisation owns, in its own jurisdiction, with no sub-processor list to track.
• Enough depth in each studio that people do not route around it, because a governed system that everybody avoids governs nothing.
• A credible exit: exportable data, verifiable records, no capture, tested before signature rather than discovered at renewal.

The fifth test is the one that separates consolidation from lock-in, and it is the one a board should press hardest, including on us.

Where does a CIO start when rip and replace is not credible?

By counting the right thing. Nobody replaces twenty products in a quarter and nobody should try. Inventory the estate by boundary rather than by licence, then sort it by class of workload: work that would be embarrassing to lose, work that would be expensive to lose, and work that must be explainable to a regulator or a court. The third class is usually far smaller than the estate and far larger than the budget assumes. Consolidate that class first, inside one boundary, with one record, and leave the rest exactly where it is. The goal was never one vendor for everything. Cloud remains the right answer for a great deal of work, and best-of-breed will keep winning the categories it deserves to win. The goal is that the accountable class of work happens somewhere the organisation can actually account for it.

Frequently asked questions

Does consolidation mean taking away the tools our teams like?

No. The argument applies to the class of work that carries institutional accountability, not to every task in the organisation. Specialist design software, niche analytics, a category leader that a small team depends on: all of it can stay where it is, and forcing it out would cost more than it saves. What should not stay scattered is the record of consequential decisions and the copy of the data those decisions were made on.

Is this not lock-in with a better story?

It is, unless the exit is tested before signature. The fair test has three parts: can the organisation export its data in a usable form, can it verify its own audit record without the vendor's cooperation, and does it own the hardware the system runs on. Mickai answers all three by running offline on hardware the organisation owns and by making the Open Audit Record verifiable by an outsider with no access to us. Any consolidation proposal that cannot answer all three should be refused, ours included.

How many products should a workplace have?

There is no correct number of products, and anybody offering one is selling something. There is a correct number of trust boundaries for regulated work, and it is one. An organisation can run forty specialist products and still be well governed, provided the decisions it may have to defend are made, sealed and recorded inside a single boundary that it controls.

Can we consolidate the audit record without consolidating the products?

Partly, and it is worth doing, but it does not arrive at the same place. Streaming twenty log sources into one platform produces a very good reconstruction, and a good reconstruction beats no reconstruction. It remains an after-the-fact account, assembled from what each product chose to emit, in formats the vendor can change, with retention the vendor controls. Sealing an action before it executes is a different class of claim, and it is the class that survives cross-examination.

Mickai is a British Sovereign Intelligence Operating System: built, live, and running offline on hardware the organisation owns, in its own jurisdiction. Email, meetings, collaboration, knowledge and the departmental studios sit inside one boundary, with agents confined to a gated sandbox under per-action clearance, and every consequential action sealed before it executes into the Open Audit Record, signed with post-quantum FIPS 204 ML-DSA-65 and hash-chained so a regulator or a court can verify it offline, without us. The architecture is protected by 104 filed UK patent applications carrying 2,340 claims, owned by Mickai LTD. Start at /sovereign-ai, read how the record works at /oar, and if the open question is where your own estate stands today, begin at /ai-readiness.