The AI Strategy Guide logo The AI Strategy Guide at the cusp of AI Subscribe →
Enterprise AI Copilots: The Procurement Reality of Glean, Moveworks, M365 Copilot and the Rest — Capabilities illustration

Enterprise AI Copilots: The Procurement Reality of Glean, Moveworks, M365 Copilot and the Rest

Tom Prommer · CIO/CTOUpdated 2026-05-3017 min read

The procurement review I want to describe happened in a London board room in February. The CIO of a mid-cap retailer had three contracts in front of her, totalling £4.1M annual run-rate. Microsoft 365 Copilot, already on the books at £2.6M for 9,000 seats. Glean, proposed at £900k for the same population. Salesforce Agentforce, bundled into the next Salesforce true-up at £600k incremental. The Chief People Officer wanted Moveworks for HR-and-IT support, another £400k. The CFO asked the question nobody had been able to answer in three prior meetings: which of these are we keeping in twelve months, and which are we cutting. The answers in the room were vendor-shaped. Microsoft’s account team had explained why M365 Copilot did everything. Glean’s had explained why M365 Copilot saw nothing outside Microsoft. Salesforce had explained why Agentforce was the only one that knew the customer record. Moveworks had explained why neither of the others understood IT tickets. All four were partly right. None of the four answered the consolidation question because none of them could afford to.

This is what enterprise AI copilots look like in 2026. The procurement question is not which tool — the tools are mostly adequate at the work they are sold for — it is how many you end up paying for, which of them earn their incremental seat, and what your CISO needs to have signed before any of them index a single SharePoint folder. The published productivity numbers are vendor-shaped. The data-access compliance question is load-bearing and under-discussed. The consolidation pressure is real and will compound through 2027. This page is the operator view of that mess, written without any commercial interest in selling you a copilot, and explicitly excluded from the engineer-facing tooling work that lives on the AI coding tools hub — what follows is the productivity layer for the 70% of your headcount that does not write code.

The three archetypes, named and bounded

Every workplace AI copilot in the enterprise market in 2026 sits in one of three archetypes. The vendors will resist this taxonomy because their commercial interest is to look broader than they are. The taxonomy holds anyway, and naming it before the demos start saves the same nine months the governance tooling piece names for the governance market.

Incumbent-platform copilots. Microsoft 365 Copilot, Salesforce Agentforce, SAP Joule, ServiceNow AI Agents, Google Gemini for Workspace, Atlassian Rovo, Oracle AI Agents, Adobe AI Foundry. The defining feature is not the model behind them — most of them route to OpenAI, Anthropic, or Google models, sometimes with a thin in-house layer on top — it is that they are sold by the platform vendor whose data they already see. M365 Copilot sees the Microsoft Graph because it is built into it. Agentforce sees the Salesforce data model because it lives there. Joule sees the SAP transaction graph because it is part of SAP. The integration depth is native, the procurement is bundled into seats the buyer already owns, and the marginal cost looks low because the vendor amortises the model bill across an existing customer relationship. The structural limitation is symmetric: each one sees only its own platform’s data, and your knowledge is not organised the way any one vendor’s platform is organised.

Horizontal AI search and employee assistants. Glean, Moveworks. The defining feature is that they index across your SaaS estate — connectors into Microsoft 365, Google Workspace, Slack, Jira, Confluence, ServiceNow, Salesforce, Notion, Box, Dropbox, and the long tail of niche tools — and present a single retrieval-augmented surface over the whole knowledge graph. Glean leads on enterprise search and assistant breadth; Moveworks leads on the HR-and-IT support automation use case but has been extending into general workplace assistance. The procurement question they answer is the one the incumbent-platform copilots cannot: how does an employee find an answer that is spread across six SaaS tools owned by four different department leads. The structural limitation is the inverse — these tools see breadth but not depth. They can find the document; they cannot finish the workflow inside the source system the way M365 Copilot can complete an Outlook email or Agentforce can update an opportunity.

Vertical SaaS-AI copilots. ServiceNow AI Agents inside the IT-service-management workflow, SAP Joule inside finance and supply chain, IBM watsonx Assistant inside customer-service operations, Atlassian Rovo inside engineering-team documentation, Adobe AI Foundry inside the creative production stack. The defining feature is workflow ownership rather than data ownership — these tools are sold to the function lead (the CIO for ITSM, the CFO for finance, the COO for operations) and earn their licence inside that function’s own metrics. The procurement question they answer is can we automate this specific workflow inside the system that already runs it. The structural limitation is that they are cross-functional only inside their own product’s footprint; the moment the workflow crosses a system boundary, the copilot stops.

Most enterprises in 2026 end up paying for one from each archetype. The CIO buys M365 Copilot because Microsoft made it a default Office 365 line item. The Chief Knowledge Officer or Head of Operations buys Glean or Moveworks because the M365 Copilot does not search outside Microsoft. The CRO buys Agentforce because Salesforce sold it inside the next renewal. The CIO buys ServiceNow AI Agents because the ITSM platform is already ServiceNow and the AI module costs less than the integration work to bolt anything else on. By Q3 of year two, the same enterprise is paying £3M–£8M a year across the three archetypes and nobody has audited whether the workforce is actually using more than one of them. This is the consolidation conversation the procurement leads are not having.

Microsoft 365 Copilot, in plain English

M365 Copilot is the default purchase in any Microsoft-anchored enterprise, and the default is increasingly indefensible to challenge for the workforce-wide deployment. The seat price has settled around $30/user/month for the enterprise SKU, the integration with Outlook, Word, Excel, PowerPoint, Teams, OneDrive, and SharePoint is native because Microsoft owns the surface, and the model layer is now multi-provider behind the scenes — Microsoft has been routing more traffic to Anthropic Claude models for specific workloads through 2026, which is a procurement signal worth noting because the what model is answering my question question has become non-trivial.

The honest weakness is the one the demo videos hide. M365 Copilot is bounded by the Microsoft Graph. It sees what is in Microsoft 365, Dynamics, and the small set of Power Platform connectors Microsoft has built out. It does not natively see Salesforce, Workday, ServiceNow, the engineering team’s Jira, the support team’s Zendesk, or the operations team’s Notion. The Microsoft answer is Graph Connectors, which are real but require integration work that surfaces every governance question deferred from the original M365 rollout — and the connectors expose data into the copilot’s retrieval layer at the source system’s permission model, which is usually wrong.

The procurement signal that M365 Copilot is the right primary copilot is straightforward: the percentage of an employee’s daily work that happens inside the Microsoft Graph. Above 70%, the copilot earns its seat for that population. Between 40% and 70%, the copilot is one of three tools that population needs, and the consolidation question is open. Below 40% — most engineering organisations, most creative organisations, most companies whose work happens in non-Microsoft SaaS — the seat is being paid for but not used, and the procurement decision was made by someone other than the user.

The data-access compliance question is the largest single blocker on a credible deployment. M365 Copilot inherits the access controls of the underlying source systems. SharePoint has well-documented oversharing problems in most large enterprises — the open to everyone in the org default that nobody has audited in five years. Copilot will surface that oversharing through search and chat answers, and the workforce will discover documents the security team had assumed were tightly held. The mitigation is Microsoft Purview’s permissions-analytics work, the Restricted SharePoint Search feature (which limits Copilot to admin-approved sites until the cleanup is done), and a phased rollout that pairs Copilot enablement with permission remediation per business unit. The order matters. Enabling Copilot before the remediation is the privacy-incident pattern.

Salesforce Agentforce, and the CRM-as-copilot question

Agentforce is the most aggressive of the incumbent-platform copilots in 2026. Salesforce has rebuilt the messaging from Einstein, our AI features inside Salesforce to Agentforce, our agentic platform and is pricing it on a consumption model (per-conversation) that is genuinely different from the M365 seat model. The marketing claim is that Agentforce can run autonomous agent flows — service-tier ticket resolution, lead qualification, account-research preparation for sales — without an employee in the loop. The reality is more bounded than the marketing.

Agentforce works best inside the Salesforce data model on workflows Salesforce has the configuration surface for. Service Cloud-based ticket triage and customer-history summarisation are mature. Sales Cloud-based account-research and meeting-preparation flows are competent. The agentic-flow claim is real for narrow, well-scoped workflows; it is marketing-shaped for the replace your sales rep level claim that surfaces in customer-facing collateral. The realised utility I have seen in three engagements with Agentforce in early production is meaningful but narrower than the licence model assumes — the per-conversation pricing means the workflows that pay back are the ones where the agent closes the loop without human intervention, and most workflows still need an employee to validate or escalate.

The procurement signal is the same shape as for M365 Copilot: where does the workforce population’s daily work actually happen. For sales and service organisations whose primary surface is Salesforce, Agentforce is the right primary copilot for those teams, separate from the M365 Copilot purchase for the rest of the workforce. For sales organisations whose reps work mostly in Outlook with Salesforce as a record-keeping afterthought, the M365 Copilot purchase will see more of the actual work and the Agentforce premium is harder to justify.

The data-access question is gentler here than for M365 Copilot because Salesforce’s permission model has historically been tighter, but the Trust Layer claim — Salesforce’s wrapper that controls what data flows to which model provider, with PII masking and audit logging — is the artefact your CISO will want to see in writing. Salesforce publishes the Trust Layer architecture; read the actual documentation, not the marketing summary. The questions to ask are about data residency for the model calls, what is logged where, and what happens when Salesforce changes the underlying model provider.

SAP Joule, ServiceNow AI Agents, Atlassian Rovo, Oracle AI Agents, Adobe AI Foundry, IBM watsonx

The vertical SaaS-AI copilots are the under-discussed category because they do not look like a procurement decision — they look like a renewal upsell. The pattern is consistent: the platform vendor introduces an AI module inside the existing platform contract, prices it as an add-on that looks reasonable per-seat, and earns the procurement inside the function lead’s budget rather than the central AI strategy.

SAP Joule lives inside the SAP transactional estate — S/4HANA, SuccessFactors, Ariba, Concur — and sells against the use case of natural-language access to the SAP data your finance, HR, and procurement teams cannot extract today without a consultant. For SAP-anchored enterprises, the value proposition is real because the alternative (custom Fiori apps, third-party data-warehouse projects, BI tools that lag the source system by days) has been the persistent pain point in SAP shops for a decade. Joule does not solve every SAP usability problem, but it solves a specific class of them well, and the procurement is a renewal-cycle decision rather than a standalone purchase.

ServiceNow AI Agents sit inside the ITSM workflow and earn their licence on ticket-deflection and incident-summarisation metrics. The integration with the existing ServiceNow estate is automatic, the workflows are configurable in the same surface the platform team already uses, and the metric is concrete (deflected tickets per dollar of AI spend). The strongest fit is in enterprises whose ITSM is already ServiceNow-centric; the platform answers the IT-support automation question that Moveworks also answers, but inside ServiceNow rather than alongside it.

Atlassian Rovo is the most recent of the vertical entrants, sold into Jira and Confluence as a knowledge-and-search layer for engineering and product teams. The procurement signal is whether your engineering organisation is Atlassian-anchored; if so, Rovo is competitive with Glean for the engineering-knowledge slice of the search problem at lower marginal cost, but it does not see outside Atlassian and pairs naturally with a broader horizontal tool for the rest of the workforce.

Oracle AI Agents are the Oracle Cloud Applications response — agentic flows inside Fusion Cloud HCM, ERP, and SCM. The fit is symmetrical to SAP Joule: strong for Oracle-anchored enterprises, irrelevant for everyone else. The procurement is a renewal-cycle add-on rather than a standalone evaluation.

Adobe AI Foundry covers the creative-production workflow — copy generation, asset variation, brand-compliance checking inside Creative Cloud and Experience Cloud. The procurement signal is the size of the creative production function and the marketing operations team’s commitment to Adobe. For Adobe-anchored enterprises with substantial creative-production volume, Foundry is a real productivity layer; for everyone else, it is a niche purchase the marketing department leads.

IBM watsonx Assistant is the customer-service-oriented copilot inside the broader watsonx portfolio. The fit is strongest where the enterprise is already an IBM customer service shop and the watsonx procurement is part of a broader IBM commitment. As a standalone purchase against Glean or Salesforce Agentforce for the same use case, the procurement is harder to defend in 2026; IBM’s strength in this category has been the regulated-industry posture, not the agent-quality leadership.

Google Gemini for Workspace is the M365 Copilot analogue for Workspace-anchored enterprises. The integration depth into Gmail, Docs, Sheets, Slides, Drive, and Chat is native because Google owns the surface, and the model layer is Google’s own Gemini family. The procurement signal mirrors M365: above 70% of work in Workspace, the purchase is the default; below 40%, the seat is paid for and not used. The realised quality of Gemini for Workspace has improved materially through 2025 and 2026 and is now competitive with M365 Copilot inside the Workspace estate, which was not true two years ago.

Glean and Moveworks: the horizontal-search archetype

This is the category that the incumbent-platform copilots cannot replicate without conceding the limit of their own platform. Glean and Moveworks are sold against the structural problem that the modern enterprise’s knowledge is spread across forty SaaS tools, no employee remembers where any given answer lives, and the answer is rarely in the same SaaS tool the employee happens to be working in when they need it.

Glean is the broader of the two. The platform indexes across the enterprise SaaS estate — typically 30–50 connectors in a mature deployment — and presents a single search-and-assistant surface that retrieves across the whole knowledge graph. The integration model is connector-based, the permission inheritance is preserved from the source system (the same oversharing problem M365 Copilot has, with the same Microsoft Purview-style remediation requirement), and the assistant layer on top has been competitive with the incumbent copilots for general-purpose Q&A and document drafting. The list price is in the $40–$50 per user per month range for the enterprise tier, which is more than M365 Copilot per seat but covers the workforce population the M365 Copilot does not reach effectively.

The honest read on Glean: the value proposition is real for the workforce population whose work spans more than three or four major SaaS surfaces, and the value is hard to capture in the incumbent platforms because the incumbents’ commercial interest is to absorb the work into their own surface. Glean’s commercial interest is to keep the work where it is and provide a horizontal layer over it. For most enterprises with a heterogeneous SaaS estate, the answer to do we need Glean alongside M365 Copilot is yes for the population whose work is not Microsoft-centric, and the consolidation pressure to drop Glean is mostly procurement noise rather than user signal.

Moveworks is narrower and was originally focused on the HR-and-IT support automation use case — the chatbot interface for employee-facing requests (password resets, PTO questions, IT ticket creation) that previously required a service-desk interaction. Through 2025 and 2026, Moveworks has been broadening into general workplace assistance, but the centre of gravity is still the support-deflection use case, and the strongest ROI story is the one the HR and IT functions can quantify in deflected tickets and reduced service-desk hours. The procurement signal is the size and cost of the existing employee-support function; for enterprises with large support backlogs and high cost-per-ticket, Moveworks earns its licence on deflection metrics alone, before any productivity claim.

Glean vs Moveworks as a head-to-head procurement: rarely the right framing. Glean is a horizontal search and assistant for all-employee knowledge work; Moveworks is an employee-service automation layer. The overlap is real (both surface answers from indexed enterprise content; both provide a chat interface) but the centre of gravity is different. Enterprises that buy both — and several large ones have — use Glean for the general knowledge-work assistant and Moveworks for the employee-service automation, and the consolidation pressure between them is lower than the procurement teams initially assume.

Glean vs M365 Copilot as a head-to-head: also rarely the right framing. M365 Copilot’s deep integration with Office surfaces makes it the right tool for in-app drafting, in-mailbox summarisation, in-spreadsheet analysis. Glean’s breadth across the SaaS estate makes it the right tool for cross-tool search and retrieval. Most realistic deployments end up running both, paying for both, and accepting the seat-level overlap as the cost of the breadth-plus-depth coverage no single vendor sells. The honest middle path is to designate one as primary for the workforce population it best serves and treat the other as a workflow-specific tool, rather than forcing a single-vendor consolidation that the underlying knowledge graph does not support.

The data-access compliance question your CISO will sign off on

Every copilot in this category needs five compliance artefacts before deployment, and the absence of any one of them is the signal that the vendor is selling against an unprepared buyer. The framing borrows from the CISO governance piece — these are the deployment-gate criteria for the copilot category specifically.

The first is the data-access map. A documented inventory of which document repositories, mailboxes, chat archives, CRM objects, ticketing systems, and SaaS tools the copilot will index, with named technical owners for each. Most enterprises do not have this map before procurement; producing it is a two-week piece of work that most procurement teams skip because the vendor’s deployment guide makes the indexing sound automatic. It is not automatic from a governance perspective even when it is automatic from a technical one.

The second is the identity-binding model. Specifically: how does the copilot inherit permissions from the source systems, and what is the documented behaviour when the source system’s permission model is permissive (the open to anyone in the company SharePoint folder, the all engineers Slack channel, the Notion workspace where every employee has read access by default). The answer is almost always the copilot inherits the existing permissions, which means the existing oversharing becomes more discoverable. The mitigation is permission-analytics tooling (Purview for Microsoft, Varonis cross-platform, BigID for the data-discovery side) deployed before, not after, the copilot rollout.

The third is the retention and deletion policy. What does the vendor store, for how long, in which jurisdiction, with what access controls. Does the model provider behind the copilot retain prompts and responses (most enterprise contracts now exclude training on customer data, but the prompt logging for safety review is a separate question). What is the data-deletion SLA when an employee leaves and their content has been indexed. What is the response when a regulator under GDPR Article 17 asks for a deletion across the copilot’s index.

The fourth is the logging surface. The copilot will be asked questions, will return answers, and will sometimes execute actions. The security team needs an audit log of what was asked, what was answered, what was actioned, and by whom — at a level of detail that supports incident investigation. Most vendors offer admin-side logging; the question is the depth and the export path into the SIEM the security team already runs.

The fifth is the data-residency commitment and what happens when the vendor changes the underlying model provider. This is the question that has become load-bearing through 2026 as the incumbent-platform copilots have been quietly routing more traffic to multiple model providers depending on workload. Microsoft has been adding Anthropic models behind M365 Copilot for specific use cases. The contract clause that needs to survive that change is the one that names the data-residency commitment without naming the model provider, and the auditable evidence that the commitment is held in practice.

Without all five artefacts, the deployment is a privacy incident waiting for an unlucky search query. The cost of the artefacts is roughly £40,000–£80,000 of internal compliance work plus the permission-analytics tooling purchase. The cost of skipping them is not a compliance headache; it is the incident response when the all-hands SharePoint folder turns out to have been searchable by a hallucinating copilot the whole time.

The productivity numbers, honestly

The vendor-published productivity numbers from Microsoft, Salesforce, Glean, and Moveworks are not lies, but they are not the number you will see in your deployment either. The published numbers have three structural biases: the survey population is self-selected toward champion users, the comparison baseline is rarely controlled, and the time horizon is short enough to capture novelty effects but not durability. The realised number in a typical enterprise deployment runs at roughly a third to a half of the vendor-published claim once you average across all licensed seats — not just the ones who log in weekly — and the gap widens at the eighteen-month mark when the novelty effect fades and only the genuinely high-value workflows remain in active use.

This is Goodhart’s Law applied to the copilot category. The vendor measures the metric they can publish (logged-in users, queries per week, satisfaction survey responses). The enterprise needs the metric the published one is a proxy for (hours of productive work shifted to higher-value tasks, error rate reduction, cycle time on key workflows). The two correlate at the start of the deployment and diverge as the deployment matures. The enterprises that measure only the published metric ship a glowing six-month review and a flat eighteen-month one; the enterprises that measure the underlying productivity outcome have an honest read on whether the licence is earning its seat.

The pattern from the root hub opener applies here directly. Enrolment had stopped measuring the thing. For copilots specifically, the metric that matters is not whether the workforce logs in, it is whether the workforce’s output quality or velocity has changed in a way that an honest baseline would have detected. Most copilot deployments cannot answer that question because they did not measure the baseline before deployment. The deployments that pay back are the ones that named a specific workflow, measured it before the copilot was enabled, and measured it again at the six-month and twelve-month marks. The deployments that do not pay back are the ones that measured adoption and called it impact.

The Brooks corollary applies to the consolidation question. Brooks’ Law — adding people to a late project makes it later — generalises to enterprise tooling: adding more copilots to a confused knowledge graph makes the knowledge graph more confused, not less. The enterprise that buys M365 Copilot, Glean, Agentforce, Moveworks, and a vertical SaaS copilot per major function has not solved the workforce-productivity problem; it has expanded the surface area of unowned tooling and pushed the which tool do I use for this question decision down to every individual employee. The consolidation pressure is real, the consolidation answer is rarely drop one vendor entirely, and the right shape is usually designate the primary copilot for each workforce population and treat the others as workflow-specific tools owned by named functions.

The procurement methodology that survives a year

The methodology I would run, against this market, in 2026, is a sequenced one. The order matters because each step’s answer constrains the next.

Step one: produce the workforce-population map. Segment your headcount by where their daily work actually happens. Microsoft Graph-anchored populations get M365 Copilot first. Workspace-anchored populations get Google Gemini for Workspace first. Sales and service populations get Agentforce evaluated against the M365 Copilot baseline. Engineering populations get Atlassian Rovo or Glean depending on the broader knowledge-graph spread. The map is two pages and takes a week. Most procurement teams skip this step and buy by vendor relationship.

Step two: name the primary copilot for each population, and the secondary tools that earn their seat against specific workflows. The primary is the one whose seat the population uses daily; the secondary is the one whose seat is justified by a specific workflow the primary does not cover. The horizontal-search archetype (Glean or Moveworks) is almost always secondary for at least one population — usually the heterogeneous-SaaS population whose work spans multiple incumbent estates.

Step three: produce the five compliance artefacts before any rollout. The data-access map, the identity-binding model, the retention policy, the logging surface, the data-residency commitment. This work is not optional and not deferrable to post-rollout. The permission-analytics tooling purchase usually surfaces here.

Step four: measure the baseline. For each primary copilot, name two workflows that the copilot is supposed to improve, measure those workflows before deployment, and commit to remeasuring at six and twelve months. The baseline is the artefact that protects the procurement from Goodhart’s Law later.

Step five: roll out by population, not by vendor. Enable the copilot for the population it serves, in phases that respect the permission-cleanup cadence the security team needs. Cross-vendor rollout coordination is the procurement work most teams underbudget; the vendors will not coordinate with each other on your behalf.

Step six: run the consolidation review at month twelve, not month six. Six months is too early to distinguish novelty from durability. Twelve months produces an honest read on which copilots are earning their seat and which are paying for log-ins without producing work-output change. Plan the contract terms to allow consolidation at the twelve-month mark — annual or eighteen-month commitments, not multi-year — because the consolidation move is the one the vendor’s renewal cycle will resist.

This methodology costs roughly £80,000–£150,000 of internal effort and £0 in external consulting. The published consultancy version of this work runs into the £400,000 range and produces a deck that lags the actual procurement decision by a quarter. The pattern is the same as the governance tooling procurement: the artefact has become the deliverable, the artefact is not the deliverable, and the decision the methodology produces is the deliverable.

What I would do, by enterprise shape

A pragmatic short list, scoped to enterprise shape rather than to vendor preference.

For a Microsoft-anchored enterprise with substantial non-Microsoft SaaS spread: M365 Copilot for the Microsoft-centric population, Glean for the cross-SaaS knowledge-work population, Moveworks or ServiceNow AI Agents for the IT-support automation use case if the support backlog is large enough to justify it. Defer Agentforce until the sales organisation specifically asks for it, and defer SAP Joule, Oracle AI Agents, and Adobe AI Foundry until the relevant function leads commission them with their own ROI cases.

For a Google Workspace-anchored enterprise: Gemini for Workspace as primary, Glean as the cross-SaaS overlay for the populations whose work spans outside Workspace, Atlassian Rovo for the engineering knowledge slice if Atlassian is the standard. Skip M365 Copilot entirely unless the dual-platform commitment is real (it rarely is in mature Workspace shops).

For a Salesforce-anchored sales-and-service-led enterprise: Agentforce as primary for the sales and service populations, with the per-conversation pricing modelled carefully against the expected agent-resolution rate. M365 Copilot or Workspace Gemini as the productivity layer for non-customer-facing functions. Glean as the cross-SaaS layer if the knowledge graph is heterogeneous.

For an SAP-anchored enterprise with substantial finance, HR, and supply chain workflows: SAP Joule as the vertical copilot for those functions, M365 Copilot or Workspace Gemini for the broader workforce productivity layer, and Glean as the cross-SaaS overlay if the knowledge graph is heterogeneous. The Joule procurement is a renewal-cycle add-on rather than a standalone evaluation.

For a heterogeneous-SaaS, multi-cloud enterprise with no dominant platform: Glean as the primary horizontal layer, function-specific vertical copilots only where the function lead has a specific ROI case, and a deliberate decision to defer the workforce-wide incumbent-platform copilot until the knowledge graph is cleaner. Buying M365 Copilot for a population whose work does not live in Microsoft is the most common procurement error in this shape.

None of these recommendations come with a referral fee or a sponsorship. The full workforce-population mapping template and the five-artefact CISO sign-off checklist are CC-BY-4.0 and linked from the capabilities hub. The honest signal of a working copilot deployment is that the workforce prefers the new tool over the old workflow at month twelve, after the novelty has worn off, and the underlying business workflows have measurably changed. The signal of a failing one is that the workforce keeps doing the work the way they used to, the copilot login metrics look fine, and the eighteen-month review will be flat. Pick the methodology that lets you tell which of those two is true before the next renewal cycle locks you in.

Sources

Methodology: workforce-population mapping, primary/secondary copilot designation, and five-artefact CISO sign-off drawn from fractional CTO and CIO engagements (2024–2026) where copilot procurements were either run cleanly against the methodology and survived the twelve-month consolidation review, or were not and produced the consolidation conversation the original procurement should have prevented. The scoring sheet and the artefact templates are published under CC-BY-4.0 and linked from the capabilities hub. Fork them, change the weights, publish a variant with different verdicts for your sector and send me the link; I will reference the fork from the next refresh.

Frequently asked questions

Should we standardise on one copilot or run several in parallel?
Most enterprises end up paying for two or three, and the consolidation move is harder than the procurement teams expect. Microsoft 365 Copilot is bundled into seats the CIO already owns, Salesforce Agentforce ships inside the sales-cloud contract the CRO already signed, and a horizontal search tool like Glean or Moveworks is purchased separately because the first two only see their own data. Consolidating to one means losing the data surface the other two had native access to. The honest middle path is to name a primary copilot for the workforce — usually M365 Copilot in Microsoft-anchored shops — and explicitly designate the others as workflow-specific tools rather than competitors.
What does the CISO actually need to sign off before a copilot indexes corporate data?
Five artefacts. A data-access map showing which document repositories, mailboxes, chat archives, and SaaS objects the copilot will index. An identity-binding model showing how the copilot inherits permissions from the source systems and whether oversharing in those systems will surface in copilot answers (it will). A retention and deletion policy showing what the vendor stores, for how long, and under whose jurisdiction. A logging surface the security team can audit. And a data-residency commitment that survives the vendor's underlying model provider change. Without those five, the deployment is a privacy incident waiting for an unlucky search query.
Are the published productivity numbers from Microsoft, Salesforce, and Glean trustworthy?
Treat them as marketing-shaped. The methodology is rarely disclosed, the comparison baseline is rarely controlled, and the survey populations skew toward champion users who self-select into the case studies. The Microsoft Work Trend Index numbers and the Glean ROI calculators are not lies — they are upper-bound estimates from favourable conditions. The realised number in a typical enterprise deployment runs at roughly a third to a half of the vendor-published claim once you average across all licensed seats, not just the ones who log in weekly. Plan against the lower number; treat the higher number as the headroom if you get adoption right.
What is the procurement category most teams underbuy?
Permission hygiene tooling. Every enterprise copilot inherits the access controls of its underlying data sources, and most underlying data sources have years of oversharing that nobody has cleaned up. The copilot does not create the privacy risk; it surfaces the risk that was already there. Microsoft Purview, Varonis, and similar permission-analytics tools are not glamorous purchases, but they are the prerequisite without which a copilot deployment becomes an audit finding. Budget the permission cleanup before the copilot licence, not after.
What is the realistic timeline from copilot decision to measurable productivity impact?
Twelve to eighteen months for measurable impact at the team level, three to six months for measurable adoption, and a depressing two to four years for measurable enterprise-level financial outcomes. The adoption curve is faster than the impact curve because logging in is not the same as getting work done, and the gap between the two is the metric the [root hub](/) opens with. Teams that confuse adoption for impact ship a glowing six-month review and a flat eighteen-month one. Plan the measurement regime against the eighteen-month curve; the six-month one will look fine regardless.