Microsoft's June 2026 customer reel quietly moved the goalposts. The wins they showed were not Copilot seats helping a knowledge worker write faster. They were entire processes regenerated end to end, with the LLM as one executor inside a deterministic harness.

Key takeaways

The UniFi 30x cost cut is a process rebuild on Power Platform plus Copilot Studio, not a per-seat assist win, and it is the only verbatim-verified number from the Cunningham keynote.
Microsoft's internal 500,000 agents and 65,000 daily responses are vendor-reported, not independently audited, and they describe a rebuild fleet, not a Copilot deployment.
The NASA 47K monthly active user claim and the 36 hours to 2 hours quote-gen "moonshot" are stage assertions, not customer stories, and should be quoted that way.
For a 20 to 200 person SMB, the math says cancel half the Copilot Business seats and put the saved money into rebuilding one quote-to-cash or onboarding workflow on Copilot Studio plus Dataverse.
Process rebuild loses when the rebuild target is a poorly understood workflow or when nobody owns the Power Platform environment, and the 5 percent pilot-to-deployment rate is the receipt.

Stop buying Copilot seats, rebuild one process instead

A 60-person operations lead at a German Mittelstand logistics firm does not need 60 Copilot seats. She needs the quote-to-dispatch workflow to stop feeling like 9 apps stitched together by humans copying fields between tabs. That distinction, between making a person faster inside a broken process and rebuilding the process so the broken parts no longer exist, is the only honest reading of Ryan Cunningham's June 2026 Microsoft Developer keynote (watch here). The customer proofs he showed all run the same direction, and Microsoft's marketing department has not yet caught up with what its product strategy is actually doing.

Here is my thesis, the one I want you to push back on if you disagree. Process rebuild beats assistance. The wins everyone is quoting from that keynote, UniFi's 30x cost cut, NASA's near-universal Power Platform adoption, Microsoft's own internal half-million agent fleet, are not Copilot Business seat wins. They are rebuilds where the LLM is a component inside a deterministic Power Platform plus Dataverse plus Copilot Studio harness. The SMB takeaway is unambiguous: stop buying seats by the headcount and rebuild one workflow.

What process rebuild actually means

Process rebuild is the workflow itself regenerated end to end, with the LLM as one executor inside a deterministic harness, not a chat surface bolted on top of an unchanged stack. The distinction matters because per-seat assist economics assume the underlying process is fine and a person is the bottleneck. They are not, and they are usually not, respectively.

The assist pattern looks like this. Procurement still routes through five inboxes, three spreadsheets, and a SAP screen nobody trained the new hire on. Copilot helps the new hire draft the supplier email faster. The process is still 9 apps stitched by humans, but each human step is 12 percent quicker.

The rebuild pattern looks different. The supplier intake form lives in Dataverse. A Copilot Studio agent reads the inbound PDF, extracts the line items, checks them against an approved-supplier table, and routes to either auto-approve or human review via the Power Platform MCP layer. The five inboxes collapse into one queue. The spreadsheets disappear. The SAP screen becomes one MCP-mediated write at the end. The human is not faster inside the old process; the old process no longer exists.

Cunningham's framing for the substrate is Work IQ: the chat, context, tools, and workspaces layer where emails, Teams messages, SharePoint files, and Dataverse rows are all addressable as one semantic surface. That is the load-bearing claim. Rebuild is feasible when the substrate already has the data; if your company's institutional memory lives in PDFs on a fileserver nobody indexes, you do not have a Work IQ, you have a paperwork museum, and rebuild is much harder. Call this the data-gravity problem: the substrate has to exist before any agent can do useful work on top of it.

Which Cunningham numbers actually hold up

The keynote spent most of its energy on three numbers. Only one of them survives a primary-source check.

UniFi 30x: verified. The verbatim quote on the Microsoft Customer Stories page for UniFi reads, "delivers the same performance as off-the-shelf products costing 30 times more." That is the strongest claim in the talk, and it survives. The case study also reports contract processing dropping from days to minutes, with 100 percent OCR accuracy versus manual extractions, and ship time under two months. Notice what is not in the page: the name of the off-the-shelf product being compared against. That is a real hole. Vendor-friendly comparisons typically pick the highest-cost incumbent. Even halved, 15x is still a process-rebuild win.

500,000 internal Microsoft agents: vendor-reported only. The number appears in Techtimes reporting attributed to Microsoft, with the explicit note that it is "vendor-reported figures and have not been independently audited." Use it with that asterisk visible. The directional signal, an enterprise running at agent-fleet scale internally before pushing it externally, is meaningful. The exact count is not.

NASA 47,000 monthly active users: stage claim only. I went looking for a Microsoft customer story page that enumerates the 47K figure and the 800 production solutions. It is not there. The number came from a stage exchange between Cunningham and a NASA representative at the Microsoft 365 Conference 2026, and that is the canonical source. Quote it as Cunningham claimed it from the stage. Do not promote it to "verified customer outcome."

36 hours to 2 hours quote generation: stage assertion only. This one travelled. Cunningham named it as a customer's "moonshot" goal he met last month. It is not in any Microsoft customer story I could find. The closest verifiable numbers are DLA Piper saving up to 36 hours weekly on content generation and Rajah and Tann compressing meeting-minute drafting from one to two days down to two to three hours. Adjacent, but not the same claim. Treat the 36 to 2 number as a customer aspiration Cunningham repeated, not as a shipped benchmark.

And one attribution correction. Co-work was announced 2026-05-05 by Charles Lamanna, EVP Business Applications and Agents, not by Cunningham. Cunningham demoed it. Lamanna shipped it. Attribute correctly.

Why per-seat assist hits a ceiling

The per-seat economics break down at the SMB scale faster than at the enterprise scale, and that is the part the Microsoft sales motion is least incentivized to surface.

Microsoft 365 Copilot Business is $18 per user per month through 2026-06-30, rising to $21, and requires a qualifying Microsoft 365 Business plan underneath. For a 60-seat firm, that is roughly 13,000 EUR per year just for Copilot, on top of the M365 Business Premium licence. The break-even claim is that each user saves enough time to justify the seat. The data does not support that at the median.

Microsoft's marketing has been brilliant. Execution, not as strong as the marketing.

That is Gartner analyst Dan Wilson, quoted in techpartner.news reporting on Copilot ROI realities. The piece also names the receipt: only 5 percent of organizations that piloted M365 Copilot in 2025 moved to broader deployment. The Forrester TEI study Microsoft commissioned projects 116 percent ROI over three years on a 25,000-employee deployment, but that is a vendor-funded model on enterprise headcount, not a 60-person Mittelstand reality.

The structural problem with per-seat assist is that it has no compounding mechanism. Each seat saves a marginal amount of time on tasks the seat-holder already does, and that saving evaporates the moment the seat-holder leaves or changes role. A rebuilt process compounds. Once the Dataverse schema is right, every new ingestion improves it. Once the Copilot Studio agent is governing routing, every new edge case is a one-time fix, not a per-seat repetition.

💡 Per-seat AI saves minutes per user. Process rebuild removes the role entirely from the bottleneck path.

The 60-person logistics firm: a worked SMB scenario

Take a real Mittelstand stack. A 60-person regional freight forwarder running Microsoft 365 Business Premium, Power Apps per-app plan for two existing forms, Copilot Studio messages pay-as-you-go pooled at the tenant, and a SAP Business One backend they will not rip out before 2028. The operations lead, call her Antje, owns quote-to-dispatch.

The current quote process: a request lands in a shared inbox; an ops coordinator opens it, copies fields into a Smartsheet, pings a senior dispatcher in Teams, waits for capacity confirmation, opens SAP Business One, generates a quote PDF, emails it back, and updates the Smartsheet. Median wall-clock time, 4 hours. Variance, plus or minus 18 hours depending on who is on shift. They handle roughly 90 quote requests per week.

The rebuild target Antje names on Monday: cut median quote time to 30 minutes, kill the Smartsheet, and stop pinging the senior dispatcher for capacity unless the route is non-standard. She does not name a Copilot seat count. That is the right framing.

The build: a Copilot Studio agent reads the inbound email, extracts origin, destination, weight, and required pickup window via a Copilot Studio prompt with a Dataverse-backed extraction template. It looks up route in a new Dataverse table seeded from last year's quote history, returns a quote band, and posts to Antje's queue with a "auto-send if within band, escalate to dispatcher if out of band" rule. SAP Business One write happens at the end via an MCP server wired into Power Platform. Total estimated build time, two weeks, one Power Platform-literate contractor at 800 EUR per day. Total estimated cost, 16,000 EUR plus roughly 200 EUR per month in Copilot Studio messages. Compared to 13,000 EUR per year in seats with no compounding, the rebuild pays back inside the first year and keeps paying.

The key constraint: Antje must own the workflow definition. Not the IT director. Not the contractor. If the person who owns the rebuild does not also own the process, the rebuild ships the contractor's interpretation, not Antje's reality, and the 5 percent pilot-to-deployment rate is exactly that failure mode at scale.

The build pattern: Work IQ as substrate, Dataverse as spine

For Microsoft-house shops the build pattern is now stable enough to name. Work IQ is the substrate, addressable via Microsoft Graph plus Copilot connectors. Dataverse is the spine where rebuilt process state lives. Copilot Studio is the agent layer that reads Work IQ, writes Dataverse, and calls out to legacy systems via MCP. The rebuilt UI on top, if you need one, is generated by enterprise vibe coding at vibe.powerapps.com, with Microsoft pointing at NASA's Power Platform footprint as the proof point that the substrate scales.

For non-Microsoft shops the equivalent pattern is the same shape: an n8n or Temporal workflow engine for the deterministic harness, Postgres or Supabase as the spine, Anthropic or OpenAI as the LLM executor, and Okta or Auth0 as the agent identity layer. The pattern is portable; the lock-in is in which spine you pick. I have written about the governance bottleneck this creates in a prior post; that bottleneck is real and it lives downstream of the rebuild, not before it.

A concrete first-day artifact. Here is a Power Platform CLI bootstrap that creates the environment, the Dataverse table, and the Copilot Studio solution scaffold for the freight scenario above:

# Power Platform CLI v1.34+
# https://learn.microsoft.com/en-us/power-platform/developer/cli/introduction
pac auth create --name ops-rebuild --environment "Antje-Quote-Dev"
pac env select --environment "Antje-Quote-Dev"

# Create the Dataverse table for quote requests
pac data create-entity --name "quote_request" --display-name "Quote Request" \
    --primary-name "request_id" --owner "user"

# Add the route-band lookup table seeded from historical CSV
pac data import --schema-file ./route-bands.xml --data-file ./route-bands-2025.csv

# Scaffold the Copilot Studio solution
pac solution init --publisher-name "freight-ops" --publisher-prefix "frt"
pac solution add-reference --path ./CopilotStudioAgents/QuoteExtractor

# Export the solution as managed for promotion to test environment
pac solution pack --zipfile ./quote-rebuild-v1.zip --folder ./src --packagetype Managed

The point is not the syntax. The point is that the first artifact of a rebuild is a Dataverse table and a managed solution, not a Copilot seat purchase order. If you cannot produce that artifact on Monday, you are not doing rebuild; you are doing assist with extra steps.

Your Monday checklist

You read this far. Here is what to do Monday morning. Not Friday. Monday.

Pick one workflow. The one your operations lead complains about most. Write it down in five sentences: trigger, current steps, current wall-clock time, current failure modes, named owner. If you cannot name the owner, stop and fix that first.
Pull the seat count and the Copilot Business spend. Compare to the budget you would have for a two-week rebuild with one contractor. The math will usually favour the rebuild.
Stand up a Power Platform development environment via the Power Platform admin center or the CLI snippet above. Free for development.
Sketch the Dataverse schema for the rebuilt workflow on a single page. If it does not fit on a single page, the workflow is not yet understood well enough to rebuild.
Build the extraction prompt in Copilot Studio against five real historical examples from your current inbox. Measure precision before doing anything else.
Define the rebuild's success criterion as a single number with a hard deadline. "Median quote time under 30 minutes by 2026-08-01" is a criterion. "Improve quote efficiency" is not.

If you want the deeper governance side of this once you ship, the Agent 365 inventory-versus-observability gap is the next read, and the Agent Flows SMB on-ramp post covers the tactical wiring after the rebuild ships.

Where the process-rebuild thesis loses

I have to name where this thesis breaks, because it does, and a 100 percent-success narrative is a tell.

Assist wins when the process is good and the bottleneck is genuinely the human's input speed. A lawyer drafting a contract with strong templates and clean precedent is faster with Copilot than without. A developer reviewing a PR is faster with GitHub Copilot agent mode than without. Those are real wins. The rebuild thesis loses against assist when the rebuild target is a process you do not understand well enough to specify. Rebuilding a workflow you cannot describe in three sentences is how you ship the contractor's hallucination of the workflow.

Schema design cost is non-trivial. Dataverse is a real database with real referential integrity. If your team has never modelled a domain into normalised tables, your first rebuild will overshoot its budget by 40 to 80 percent. I have watched this happen three times in the last 18 months. The honest mitigation is to hire a Power Platform-literate contractor for the first rebuild and write the schema in pairs.

Vendor lock-in to Power Platform plus Dataverse is real. Once your rebuilt process lives in Dataverse, the switching cost to leave is roughly the cost of the original rebuild plus the data migration. Microsoft's pricing power on Copilot Studio messages, Agent 365 at $15 per user per month standalone or bundled in E7 at $99, and downstream Microsoft 365 SKUs compounds. For a 60-person firm this is acceptable. For a 600-person firm this is the conversation you should have before signing.

The 5 percent pilot-to-deployment rate. Gartner's number is a rebuild number too, not just an assist number. Most pilots fail because there is no named process owner, no measurable success criterion, and no Monday decision. Rebuild requires those three things up front. Assist lets you skip them and feel productive anyway, which is precisely why it is harder to kill.

The honest read: process rebuild beats assist when (1) the workflow is well understood, (2) someone owns the rebuilt outcome, and (3) the Work IQ substrate already has the data. If two of three are missing, assist is the right cheap-fast bridge while you build the missing legs.

Compare notes

If you are running this decision at a 20 to 200 person firm and your numbers look different from mine, especially on the rebuild break-even or the per-seat ROI side, I want the counterexample. Reach me at marcus-duwe.de/contact. The fastest way to change my mind is a real rebuild that paid back inside six months, or a real assist deployment that compounded past year two. Both would teach me something I do not yet know.

Where I am still unsure

I am still watching three things that could update this thesis.

The first is whether the 5 percent pilot-to-deployment rate moves materially in 2026 once Agent 365 governance is general availability and the rebuild pattern is documented enough for non-Microsoft-house shops. If that number doubles, the thesis sharpens. If it does not, the rebuild path is steeper than I am claiming.

The second is whether per-message Copilot Studio pricing holds at the roughly one-cent level Smartbridge benchmarked in 2026 once usage scales. Vendor pricing on consumption is famous for resetting upward at the wrong time. I expect a re-pricing event inside 18 months and I have not modelled the SMB break-even under a 3x rate.

The third is the cross-platform agent broker question. Agent 365 syncing agents from AWS Bedrock and Google Cloud into one registry is a power play. If the broker becomes the default, rebuild becomes more portable. If it does not, Microsoft-house rebuild and non-Microsoft rebuild diverge into two different conversations.