How should Datadog price Bits AI against Microsoft Copilot in 2027?

A platform team weighing two AI line items in the FY27 budget

Picture a 900-engineer fintech running roughly 4,000 hosts in Datadog, spending about $1.1M a year across Infrastructure, APM, Log Management, and Cloud SIEM. Their platform director opens the FY27 planning cycle with two AI proposals sitting side by side on the same slide. One is Microsoft Security Copilot, which their Azure account team has already scoped: a consumption commitment measured in Security Compute Units, provisioned by the hour, that their SOC would use to accelerate alert triage inside Defender and Sentinel. The other is Bits AI, which their SREs have been using in preview and describe, unprompted, as the thing that finally makes the incident timeline assemble itself.

The trap in that slide is that both line items get labeled "AI spend" by finance, and once they share a label, they get compared on a single number. The Microsoft proposal produces a clean annual figure because provisioned SCUs are a flat hourly rate multiplied by hours. If Datadog answers with a per-user SKU, the comparison collapses to dollars per head, and Datadog loses that comparison structurally — not because Bits AI is worse, but because Microsoft's marginal cost of adding AI to an account it already owns is close to zero, while Datadog pays real inference cost to Anthropic and OpenAI on every heavy investigation. Margin math alone decides that fight before the product ever gets evaluated.

The escape is to refuse the shared label. The fintech's SOC and its SRE org are not the same buyer, do not share a budget line, and do not measure the same outcome. The SOC measures mean time to triage across a queue of Defender alerts. The SRE org measures mean time to resolution on production incidents that page humans at 3 a.m. and cost revenue per minute. Bits AI should be sold, and priced, against the second number. When the platform director's slide reads "$X per resolved production incident, verifiable in the audit trail" instead of "$Y per engineer per month," the Microsoft line item stops being a competitor and becomes an adjacent purchase in a different budget.

That reframing has to be encoded in the price model itself, not just in the pitch deck. A per-seat price is an invitation to the seat comparison no matter what the seller says on the call. A consumption-and-outcome price makes the seat comparison syntactically impossible, because there is no per-seat number to divide. This is the whole strategic argument compressed into one design decision: the unit of the price determines the axis of the competition.

How the pricing mechanism actually works end to end

The model has four layers, and the sequencing between them is what makes it hold together rather than cannibalize itself. Layer one is a free Bits AI summary tier available to every paying Datadog customer with no add-on purchase. This covers natural-language search over existing telemetry, incident summarization, and change-context lookups — the queries that cost little inference and drive daily habit. Giving these away is not generosity; it is the adoption funnel that produces the usage data every later layer is priced against. A customer who never opens Bits AI cannot be sold an investigation package.

Layer two is per-investigation outcome pricing, charged only when Bits AI runs an autonomous investigation that produces a root-cause hypothesis and a proposed remediation. The billing event is not "user asked a question" but "agent completed a multi-step investigation and emitted a conclusion," recorded in an audit trail the customer can inspect. Layer three is per-token or per-execution consumption for the heavy agentic surfaces — long-horizon agent runs, LLM Observability trace volume, custom agent workflows — where cost genuinely scales with the customer's own AI workload and a flat fee would be either extortionate or suicidal depending on the account.

Layer four is a negotiated enterprise envelope for large-ACV accounts: a committed annual AI spend that buys a discounted blended rate across layers two and three, with a hard cap the customer sets. This is the layer that makes the model sellable to procurement, because it converts a variable meter into a forecastable commitment without reverting to seats.

The critical mechanical detail is the definition of the billing event in layer two. "Resolved" cannot mean "the incident closed," because incidents close for reasons that have nothing to do with the agent, and customers will dispute every charge where a human did the real work. The defensible definition is narrower and entirely observable inside the product: the agent executed a multi-step investigation, correlated across at least two telemetry sources, and produced a written conclusion the on-call engineer either accepted or explicitly rejected. Charge on the emission of the conclusion, expose the accept/reject rate in the billing dashboard, and credit back rejected investigations automatically. That auto-credit is what converts the model's biggest liability — attribution disputes — into a trust-building feature, because the customer sees the vendor refusing to bill for its own misses.

The second mechanical detail is the cap. Every consumption meter needs a customer-set ceiling that hard-stops billing rather than merely alerting, plus a throttle-not-block behavior at the ceiling so the free tier keeps working after the paid meters stop. Consumption pricing dies in enterprise accounts the first time someone gets a surprise invoice, and the fix has to be structural rather than a support-ticket courtesy credit.

Real numbers, ranges, and the benchmarks that anchor them

Start with the competitive facts as they actually stand rather than the version that circulates in pricing decks. Microsoft Security Copilot is sold on consumption, provisioned in Security Compute Units billed hourly, not as a per-user license, and it is not included in Microsoft 365 E5. The widely-quoted $30 per user per month figure belongs to Microsoft 365 Copilot, a productivity product aimed at a different buyer entirely. Any Datadog pricing strategy built on "match the $30 seat price" is therefore built on a category error, and a competitive deck that repeats it will get corrected by the first customer who has actually bought either product.

That correction changes the strategic conclusion in a useful direction. Because Security Copilot is itself consumption-priced, Datadog choosing consumption is not a contrarian bet — it is convergence with how the serious AI security tooling market already prices. The differentiation has to come from the *unit* of consumption, not from the fact of it. Microsoft meters provisioned compute capacity, which is an input. Datadog can meter completed investigations, which is an output. Metering the output is a strictly better story in front of a CFO, because the customer can compute return per unit without knowing anything about token economics.

For the outcome layer, a defensible list range is $3 to $8 per completed autonomous investigation, with the spread set by telemetry breadth rather than by customer size — an investigation correlating across APM traces, logs, and infrastructure metrics costs meaningfully more inference than one reading a single service's error rate. For assisted investigations, where the agent supplies context and a human closes, $0.50 to $2 keeps the meter honest without discouraging use. Heavy agentic executions land around $0.50 to $2 per run depending on tool-call depth, and LLM Observability trace monitoring belongs in the cents-per-trace band because volume there scales into the millions.

Sanity-check those numbers against the value they claim. An organization resolving 200 qualifying investigations a month at $5 each spends $12,000 a year. Against a $1.1M observability commitment that is roughly a one percent uplift — small enough that it clears budget without a new approval chain, large enough to matter at portfolio scale across thousands of accounts. Now run it from the value side: if a genuine production investigation consumes four to eight engineering hours across two or three responders, and a loaded senior engineering hour is somewhere in the low hundreds of dollars, a single avoided investigation cycle is worth orders of magnitude more than the fee. A price that captures a fraction of a percent of the value it creates is not underpricing in the early years of a category — it is buying the behavioral change that makes the meter run at all.

The comparable-pricing landscape supports the shape. AI support vendors moved to per-resolution pricing rather than per-seat, and agent platforms across the enterprise software market have converged on per-conversation, per-action, or per-credit units. The pattern is consistent enough to be a market signal: when AI does discrete units of work, buyers prefer to pay per unit of work. The vendors who tried to sell AI as a percentage uplift on an existing seat price have generally had to layer a consumption model on top afterward, which is a more expensive way to arrive at the same destination.

One number deserves explicit humility. The right list price for a completed investigation is not knowable from first principles, because it depends on inference cost per investigation, accept rate, and how many investigations a typical account actually generates — none of which are stable in the first year of a product. The correct move is to launch the meter with generous included volume, instrument the three unknowns for two or three quarters, and set the durable list price from observed data rather than from a spreadsheet built before launch.

Trade-offs against the alternatives, and why each loses

Four alternatives will be argued internally, and each has a real constituency, so the case against them has to be specific rather than dismissive.

The first alternative is keeping Bits AI fully bundled into existing SKUs forever, monetized only through improved retention and expansion of core products. This is genuinely attractive: it removes all attribution disputes, it is trivially simple to sell, and it makes Bits AI a pure competitive weapon in core renewals. The fatal problem is inference cost. Bundled AI with unbounded usage means gross margin degrades with adoption, so the product's own success becomes a financial liability — precisely inverted incentives for a company whose valuation rests on software-grade margins. Bundling works for the summary tier, where cost per query is small and predictable. It does not survive contact with long-horizon agentic investigation.

The second alternative is a percentage uplift on the existing contract — the pattern several large enterprise vendors adopted, where an AI-enabled tier carries a flat markup over the base tier. It is easy to quote and easy to forecast. But it is uncorrelated with both cost and value: a customer with heavy incident volume and one with almost none pay the same uplift, so the light user overpays and churns while the heavy user is subsidized into unprofitability. It also concedes the framing that AI is a feature of the existing product rather than a distinct source of value, which is exactly the framing to avoid.

The third alternative is pure per-token pricing with no outcome layer. It is honest, it perfectly tracks cost, and it is the easiest model to defend margin-wise. The problem is that it is unsellable to the people who sign. No CFO can forecast token consumption, no engineer wants to feel a meter running while they debug an outage, and the model actively discourages the exploratory usage that makes the product sticky. Token pricing belongs underneath the outcome layer as the mechanism for genuinely unbounded workloads, not on top of it as the customer-facing story.

The fourth alternative is the per-seat SKU, and it deserves the most direct rejection because it will be the most persistently argued.

The per-seat argument always sounds reasonable in the room: it is familiar, procurement understands it, and the sales team already knows how to sell seats. But it fails on segmentation before it fails on anything else. Datadog's users are heavily concentrated in platform, SRE, and security engineering, and only a fraction of any engineering org carries the pager. A per-seat AI SKU forces the customer into a licensing decision — the whole engineering org or just the on-call rotation — and the rational answer is always the smaller number. Revenue caps out at the size of the on-call rotation, while the product's value spreads across everyone who reads a postmortem. The meter should follow the work, and the work is concentrated in incidents, not in headcount.

There is also a portfolio consideration that argues against any standalone Bits AI SKU at a small monthly number. A customer paying deep into six figures for core observability who sees a cheap standalone AI SKU will ask an uncomfortable question about what the six figures is buying. Keeping Bits AI inseparable from the platform — free at the summary layer, metered at the work layer — protects the core price architecture instead of undermining it.

Common pitfalls and how to avoid each one

The first pitfall is the false-equivalence competitive deck. Sales enablement will want a side-by-side table, and the fastest table to build is the wrong one: a per-seat Microsoft number next to a per-seat Datadog number. Since Security Copilot is consumption-priced on compute units and Microsoft 365 Copilot is a different product for a different buyer, any table that puts a seat price in the Microsoft column is factually wrong and will be corrected mid-call by a customer who has bought one of them. Build the comparison on workload instead: what a defined quantity of investigative work costs on each platform for a defined telemetry footprint, with the assumptions written on the slide.

The second pitfall is charging for agent failures. If the meter fires whenever the agent runs, customers will audit their invoices, find charges for investigations that produced nothing useful, and lose trust in the entire model — usually at renewal, when it is most expensive. Bill only on emitted conclusions, expose accept and reject rates in the billing view, and auto-credit rejections without requiring a support ticket. This costs revenue in the short term and buys the model's credibility, which is the only thing that lets outcome pricing survive its second year.

The third pitfall is letting the free tier drift into the paid tier's territory. Every product team under adoption pressure wants to make the free tier a little more capable, and each individual expansion is defensible. Cumulatively, they hollow out the paid layer until nobody buys it. Draw the boundary on a technical property rather than a marketing judgment: single-step retrieval and summarization over data the customer already pays to store is free; multi-step autonomous investigation that correlates across sources and emits a conclusion is metered. That line is inspectable in the product's own traces, so it can be enforced rather than merely intended.

The fourth pitfall is a bill-shock incident in a lighthouse account. One viral thread about a surprise five-figure AI invoice will do more damage to the model than a quarter of missed quota, and consumption vendors have collectively learned this the hard way. The mitigations are structural: default caps on every new account rather than opt-in caps, alerts at 50, 75, and 90 percent of the cap, a hard stop rather than an overage at the ceiling, and a documented policy of forgiving the first genuine runaway in any account. Publish the policy; the point is that customers know it exists before they need it.

The fifth pitfall is sales-motion fragmentation. Consumption products with variable meters compensate badly under quota plans designed for seat-based bookings, and reps will steer away from anything they cannot forecast. Compensate on committed AI envelope rather than on realized consumption, so the rep's incentive is to land the commitment and the customer success team owns drawdown. Without this, the model works on the pricing page and dies in the field, which is the most common way good pricing strategies fail.

The sixth pitfall is one that RevOps teams specifically should own: the meter has to be instrumented before the price is set, not after. Investigation counts, accept rates, inference cost per investigation class, and drawdown velocity against commitments all need to exist as reportable fields from day one of the preview, because the durable list price is an empirical question and the data to answer it only accumulates while the product is running. Launching a meter you cannot report on is how vendors end up defending a price they cannot justify.

The seventh pitfall is positioning drift. Under quota pressure, reps will start selling Bits AI against Microsoft on any axis a prospect raises, including price per head. The counter is a disciplined, repeated frame: Microsoft's assistants accelerate the analyst inside Microsoft's own security estate; Bits AI investigates production incidents across whatever infrastructure and services the customer actually runs. Those are adjacent purchases in different budgets, and a customer buying both is a normal outcome rather than a loss.

Related questions

Should Bits AI ever have a standalone SKU?

Not as a per-seat license. A standalone enterprise AI envelope — a committed annual spend drawn down by investigation and consumption meters — gives procurement a line item to approve without creating a per-head price that invites bundle comparison or devalues the core platform contract.

How do you handle a customer who disputes an investigation charge?

Auto-credit on explicit rejection, no ticket required. Surface accept and reject rates in the billing dashboard so disputes surface as data rather than as arguments, and treat a persistently low accept rate in an account as a product signal rather than a billing problem.

Does consumption pricing hurt forecastability for Datadog itself?

Less than expected, once annual commitments carry the majority of AI revenue. Committed envelopes book like subscriptions; realized drawdown becomes a usage metric that predicts expansion. The forecasting risk sits in the first several quarters, before drawdown patterns stabilize.

What is the right free-tier boundary?

Single-step retrieval and summarization over telemetry the customer already pays to store stays free. Multi-step autonomous investigation that correlates across sources and emits a conclusion is metered. The line is observable in the product's own traces, so it can be enforced consistently.

FAQ

Is Microsoft Security Copilot priced per user?

No. Microsoft sells Security Copilot on a consumption basis using Security Compute Units provisioned by the hour, and it is not included in Microsoft 365 E5. The commonly cited per-seat figure belongs to Microsoft 365 Copilot, a separate productivity product for a different buyer. Any competitive positioning that treats the two as one product will be corrected by informed customers.

Why not just bundle Bits AI into existing SKUs and never charge for it?

The free summary tier should work exactly that way, because those queries are cheap and drive adoption. Unbounded agentic investigation is a different cost structure — inference cost scales with usage, so full bundling means margin degrades as the product succeeds. Metering the expensive layer keeps the incentive to drive adoption aligned with the financial model rather than opposed to it.

What exactly counts as a billable investigation?

An agent run that executes multiple steps, correlates across at least two telemetry sources, and emits a written root-cause conclusion the responder can accept or reject. Question-answering, summarization, and single-source lookups are not billable. Rejected conclusions are automatically credited, so the customer only pays for agent output they judged useful.

How does a customer avoid an unexpected bill?

Every account gets a default spend cap rather than an opt-in one, alerts at 50, 75, and 90 percent of that cap, and a hard stop at the ceiling instead of silent overage. Paid meters stop while the free summary tier keeps working, so hitting a cap degrades capability rather than breaking the workflow entirely.

How should the sales team position Bits AI against Copilot on a call?

As adjacent purchases in different budgets. Microsoft's assistants accelerate analysts working inside Microsoft's security estate. Bits AI investigates production incidents across whatever the customer actually runs. Steer the comparison to cost per unit of investigative work with stated assumptions, and never to cost per head, where the bundle economics decide the outcome in advance.

What should RevOps instrument before the price is finalized?

Investigation volume by class, accept and reject rates, inference cost per investigation, drawdown velocity against committed envelopes, and free-to-paid conversion by account segment. The durable list price is an empirical question, so the meter and its reporting have to exist during preview — a price set before that data arrives cannot be defended when a customer challenges it.

Sources

• https://learn.microsoft.com/en-us/copilot/security/manage-usage
• https://www.microsoft.com/en-us/security/business/ai-machine-learning/microsoft-security-copilot
• https://www.microsoft.com/en-us/microsoft-365/copilot
• https://www.datadoghq.com/product/bits-ai/
• https://www.datadoghq.com/pricing/
• https://www.intercom.com/fin
• https://www.salesforce.com/agentforce/pricing/
• https://www.bvp.com/atlas/state-of-the-cloud

Related on PULSE

• [How does Datadog price Bits AI without cannibalizing core?](/knowledge/q1691)
• [Is Bits AI working for Datadog?](/knowledge/q1676)
• [Why did Datadog stock drop after Bits AI launch?](/knowledge/q1690)
• [How should ServiceNow price Now Assist against Microsoft Copilot in 2027?](/knowledge/q1664)
• [What is the difference between ChatGPT Enterprise and Microsoft Copilot for business?](/knowledge/q14493)
• [What is Microsoft Copilot for Sales and what does it mean for RevOps in 2027?](/knowledge/q12967)