On 2 November 2016, Microsoft unveiled Teams in Redmond as a chat-based workspace inside Office 365 — a suite that already counted more than 85 million monthly active commercial users. Slack bought a full-page advertisement in the New York Times the same day, an open letter welcoming Microsoft to the category and explaining, with some confidence, why the incumbent would struggle to copy what it had built. The letter was well written and largely wrong about the outcome. Not because Teams was a better product at launch — it was not — but because the competition was never really about product quality. It was about distribution, and about a procurement question that most organisations answer the same way.
The bundling argument, stated honestly
The standard explanation is that Microsoft bundled Teams into a licence customers already held and competed on price with something approaching zero. That is true and incomplete. The more precise version is that Teams removed three separate procurement decisions at once. The organisation did not need a new vendor assessment, because Microsoft was already an approved supplier with a signed data processing agreement. It did not need a new security review, because the tool inherited the tenant's identity, conditional access, retention and eDiscovery configuration. And it did not need a new budget line, because the entitlement was already in the enterprise agreement. For a CIO comparing a demonstrably better product that requires vendor onboarding, a security assessment, a separate identity integration, a new data processing agreement and an incremental spend against a merely adequate product that requires none of those things, the better product has to be substantially better to win. Often it was, for the teams that cared most. Rarely was it enough to overcome the sum of the frictions for the organisation as a whole. This is the pattern that recurs across enterprise software, and it is worth stating plainly because it predicts outcomes: in a suite market, the integration and governance advantages of the incumbent are usually worth more to the buyer than the feature advantages of the challenger, even when the buyer's own users prefer the challenger.
What the challenger got right, and what it cost them
Slack's bottom-up adoption model was genuinely effective. Teams adopted it without permission, it spread laterally, and by the time IT noticed, the tool had constituency. That route built a large installed base faster than any enterprise sales motion would have. It also created the conditions for displacement. Bottom-up adoption produces fragmented deployments — several workspaces, inconsistent administration, data in places the organisation cannot see, and no coherent retention or eDiscovery posture. When the security and compliance functions eventually looked at it, they found exactly the problems that an integrated alternative solved by default. The very characteristic that drove adoption became the argument for consolidation. The honest counterpoint: the challenger built a large, durable and valuable business, and the category it defined reshaped how work happens. "Losing" here meant being acquired for a very large sum while continuing to serve organisations that made a deliberate choice. It is a poor outcome only against a narrative that required winning the whole enterprise market.
| Area | Evidence to request |
|---|---|
| Identity and lifecycle | Joiner, mover, leaver and guest-access tests in your actual tenant. |
| Records and discovery | Applicable retention, legal hold and export behaviour with known limitations. |
| Operating ownership | Named administrator, support responsibilities and recurring integration effort. |
| Exit and residency | Content export completeness, processing locations and applicable contract terms. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What this means for platform decisions now
The useful generalisation is not "always pick the incumbent suite." It is that the evaluation criteria most organisations use are the wrong ones. Feature comparison matrices systematically favour the specialist and systematically mislead, because they weight capabilities that differentiate at demo time rather than the properties that determine cost and risk over five years. The criteria that actually predict satisfaction are: how the tool handles identity and lifecycle, whether administration is centralised, whether retention and legal hold work the way compliance needs, how much integration work is required for the systems people actually use, what the exit looks like, and whether the vendor will still be independent in five years. The second generalisation concerns adoption. Neither approach succeeds on its own. Top-down deployment produces a tool nobody uses; bottom-up adoption produces a tool nobody governs. What works is a deliberate combination — organisational defaults and governance set centrally, with genuine team-level autonomy in how the space is used — and that requires someone to own the platform after launch, which is the role most organisations never fill.
Practical Guidance for Collaboration Platform Assessment
- Evaluate integration and governance before features. Identity, lifecycle, retention, eDiscovery and administration determine the five-year cost; the feature gap usually closes.
- Count the full cost of a separate vendor, not the licence price. Security review, data processing agreement, identity integration, separate administration and separate support are real and recurring.
- Check what you already own before buying. Most organisations hold entitlements they have not deployed, and a parallel purchase is frequently a failure of inventory rather than a considered choice.
- Decide the consolidation question explicitly. Running two collaboration platforms is a legitimate choice for some organisations and an expensive accident for most; make it deliberately.
- Name a platform owner with a standing mandate. Channel structure, naming, guest access, retention and archival decay within a year without one.
- Test the external collaboration path early. Guest access, federation and partner communication are where most deployments actually struggle, and they are rarely in the pilot.
- Migrate content and retire the old tool on a date. Parallel running past a few months guarantees permanent fragmentation and doubles the search problem.
- Write down what happens to the data if you leave. Export format, completeness and effort — assess it before you depend on the platform, not during an exit.
The Regional Dimension
The Gulf market has distinct characteristics that change this calculation in both directions. Microsoft's position here is unusually strong. Public sector, large family groups, banking and the major project-driven industries are overwhelmingly Microsoft estates, frequently procured through long-standing enterprise agreements with local partners who also deliver the implementation. The suite decision is often effectively made before an evaluation begins, and a challenger has to argue against an existing relationship rather than an existing product. Residency accelerated the same outcome. The arrival of in-country cloud regions across the UAE and Saudi Arabia, and the availability of sovereign operating models for government and regulated sectors, meant the suite could satisfy a data location requirement that specialist collaboration vendors could not match — many had no regional presence at all. For a regulated buyer, that was frequently decisive on its own, independent of any feature discussion. Three local factors push the other way or complicate the picture. WhatsApp remains the incumbent communication channel across much of regional business, including at senior levels and across supplier, contractor and customer relationships. Any platform decision that ignores this produces a formal tool for internal record and an informal channel where decisions actually happen — which is a compliance problem, an evidence problem, and a real operational risk when an employee leaves and takes the conversation history with them. The second is the workforce composition: large deskless and frontline populations without corporate email or company devices, working in Arabic, English, Hindi, Urdu, Malayalam, Tagalog and more. A platform that only serves desk workers addresses a minority of many regional organisations, and multilingual usability is a deciding criterion rather than a nice-to-have. The third is the calendar and time-zone reality of regional groups — differing weekend days across markets, adjusted Ramadan hours, and entities spread from Casablanca to Karachi — which makes asynchronous, searchable, written communication more valuable here than the global average, and makes meeting-centric collaboration models correspondingly weaker. One further consideration for regional groups: multi-entity structures with different free zone and mainland regulatory positions may need different tenant configurations, guest access policies or retention settings within the same group. This is solvable inside a suite with a mature administration model and considerably harder to manage across several independent tools.
The objection worth taking seriously
The strongest argument against the reasoning above is that it rationalises a bad habit: buying from the incumbent because it is easy and calling it strategy. Bundling does suppress competition. When a dominant suite vendor includes a product at no incremental price, better products lose on economics rather than merit, innovation in the category slows, and buyers end up with a worse tool than a competitive market would have produced. Competition authorities in several jurisdictions have examined exactly this, and the concerns are not frivolous. An organisation that always takes the bundled option is not making choices at all — it is accepting the vendor's roadmap as its own, and the accumulated cost of that shows up years later as a consolidation position with no leverage in it. There is also an honest point about the users. In many organisations the people doing the most collaborative work genuinely preferred the specialist tool, and the consolidation decision made their daily experience worse to make the compliance function's job easier. That trade is often correct in aggregate and it is rarely acknowledged to the people paying for it. Naming it — and investing in the platform to close the gap — is more respectful and produces better adoption than pretending the products were equivalent. The defensible position: choose the suite when integration, governance and residency genuinely matter for your organisation, and be able to articulate why. Choose the specialist when the work your organisation does depends on capabilities the suite lacks, and accept the integration and governance cost knowingly. What is not defensible is deciding by default and describing it afterwards as a platform strategy.
Common Questions
Does the better product usually lose in enterprise software?
Not inevitably — but where a suite incumbent offers adequate functionality with superior integration and no incremental procurement, the specialist needs a very large advantage to win. Specialists succeed where the capability gap is wide enough that the work genuinely depends on it.
Is running two collaboration platforms ever right?
Yes, in specific circumstances: a distinct engineering or creative function with deep tool integration, an acquired business running separately, or external communities where partners already live on the other platform. It is right far less often than it happens, and it should be a decision with an owner and a review date.
What is the most common cause of a failed collaboration rollout?
No owner after launch. The technology deploys fine; the structure, norms and lifecycle governance decay within months, and the organisation concludes the tool failed when the operating model was never established.
How is AI changing the platform decision?
It is raising the switching cost sharply. Assistants that answer from your organisation's content are only as good as the content they can reach, which means the value now accrues to whichever platform holds the most work — messages, documents, meetings, email and calendar together. A platform that sees everything gives better answers than two that each see half, which strengthens the consolidation argument considerably and weakens the case for a best-of-breed mix. It also introduces new questions that belong in the assessment: where inference runs, what is retained, whether tenant content trains anything, and whether the AI features are available in your data residency configuration — because in several regional deployments the sovereign or in-country option lags the global one on exactly these capabilities, and that gap is now part of the platform decision rather than a footnote to it.
Collaboration Platform Assessment — the winning platform is rarely the best product; evaluate integration, governance and residency first, then decide deliberately rather than by default.