SAP is reporting adoption, which is a different number from yours

SAP published a services and support update on September 10, 2026, written by Uwe Grigoleit, its senior vice president of Customer Evolution and Portfolio. The headline figure in SAP's post is that Joule for SAP for Me has reached nearly 200,000 users year-to-date. The post also describes agentic case resolution, which it says uses AI agents to handle and resolve support cases automatically, and a unified service release model for delivering expanded capabilities.

Those are SAP's numbers about SAP's support estate. They tell you the vendor's assistant is being used widely. They tell you nothing about whether the approval workflow your partner built on SAP Business Technology Platform is why the finance team keeps raising cases, or whether a migration left half the approvers with the wrong org assignment. After go-live, that second set of numbers is the one an architecture team should read, and it lives in your own support queue.

What the post says and what we could not find in it

The post frames the portfolio as an adopt-to-operate approach connecting adoption, success planning and application management. It names three success plan tiers, Foundational, Advanced and Max, says the Foundational plan has full SAP solution area coverage, and ties its development services to SAP Business Technology Platform.

We could not find a resolution rate, a time saving, a share of cases closed by an agent, or a named customer describing what changed for them. That is normal for a portfolio update, and it means the post gives an architecture team nothing to benchmark against. If your account team brings the update to a steering meeting, ask what share of your own cases went through agentic case resolution last quarter and how they were categorised afterwards.

Every case after go-live reviews a design decision

Once a system is live, the support log becomes the most honest record of how the architecture is holding up. A case that reads "the purchase order did not reach the second approver" lands in one of four places. Standard behaviour the requester misread is a training problem, and a configuration setting is a key user's fix. A workflow extension on BTP needs a developer and a deployment, and a data problem, usually an approver whose organisational assignment was never cleaned up during migration, needs the migration team back in the room.

The count matters far less than the split across those four buckets. A system logging a few hundred cases a month that are nearly all training questions is healthy and needs better documentation. A system logging a fifth of that volume where half the cases need a developer has an architecture problem that will get worse at the next upgrade. We would tag every case by layer before we tagged it by priority.

The support queue is where clean core gets tested

SAP's post says all managed development engagements formally embed clean core principles, which it describes as helping make custom solutions upgrade-safe. That covers work SAP does itself. Whether it held for the work your partner and your own developers did is a separate question, and the support log answers it. Count the cases that needed a transport or a BTP deployment to close rather than a configuration change, and watch that number month on month. If it grows, the core is getting less clean, whatever the design documents say.

A retirement list earns its keep here too. Every extension that keeps generating cases and has a standard replacement in the next release belongs on it, with an owner and a date. We argued for a retirement list inside the modernization plan, and the support log is the cheapest way to keep it honest after the project team has moved on. More on the extension layer sits on the SAP BTP hub.

An agent that closes cases can also erase the signal

Agentic case resolution is the part of the post we'd watch most closely. If an agent resolves a case before a person sees it, the case count falls and the adoption number rises, and both are fine on their own. The risk is that the case still happened, the extension still misbehaved, and nobody categorised it, because the resolution path skipped the step where an analyst would have written down the root cause.

We'd want any agent-resolved case to sit in the same log as the cases people resolved, carry the same layer tag, and record what the agent did to close it. An empty root-cause field is the same problem whether a person or an agent left it empty, a point we made in the support signal hidden in a blank field. The post doesn't say how agent-resolved cases are reported back to the customer, and that is what we'd ask about before switching it on for anything that touches a custom object.

Bring your own split to the next architecture review

Vendor adoption figures show where the market is going and are a poor substitute for your own operating data. We said the same about what an adoption statistic can and cannot tell an implementation team after Workday's second quarter. Nearly 200,000 users of Joule for SAP for Me says the assistant is being used, and nothing about whether your key users trust what Joule tells them about your configuration. That trust depends on the business context the assistant can reach, the same constraint we described in SAP's embodied AI work.

Before the next architecture review, pull ninety days of cases from your SAP support queue, tag each one by the layer it belongs to, and count how many needed a developer to close. Bring that split to the meeting instead of the vendor's slide. Then ask the person who owns the queue one question. When an agent closes a case, who reads it?