Autonomous Service: Turning a Product Recall into a Self-Driving Claim

In Part 1, we left a manufacturer in a tight spot. Their robot vacuum was flying off the shelves, with more than 100,000 units sold in just a few weeks, when a defect surfaced and triggered a product recall. Because they don't sell directly to consumers, they can't proactively contact every affected customer. Instead, they launch a claims process: enter your product details, upload proof of purchase, and if the product was purchased within the last year, receive a free replacement along with a prepaid return label for the faulty unit. It's simple to describe. Brutal to execute tens of thousands of times.

"Can an AI agent really approve a claim on its own, without a person reviewing every receipt?" Rather than answer it with theory, let's walk through the same claim twice: first the way most service organizations handle it today, and then the way an autonomous enterprise could.

The way it works today

Every claim lands in a queue and waits for a human. A service rep opens the case, reviews the receipt, and verifies if the customer is eligible for a replacement.

• Is the proof of purchase legible?
• Is this the correct vacuum model?
• Does the serial number belong to a recalled batch?
• Was the product purchased within the one-year eligibility window?
• Is this a duplicate claim?

If everything checks out, the service rep creates the return, generates the shipping label, creates the replacement order, and notifies the customer about the next steps. Each action requires another manual step.

None of these tasks are difficult. They're simply slow. As claim volumes grow, queues build, costs rise with every new hire, and customers wait longer for answers. Two service reps read the same blurry receipt and reach different conclusions. An already unhappy customer is now frustrated with the delays in receiving a decision. This is Rung 1 from Part 1: capable people spending their time on repetitive, verifiable work instead of the exceptions that genuinely require human judgment.

Here’s the part that should bother you. None of that manual effort is where the value is. Reading a receipt isn’t a judgement call, It is a pattern recognition task that modern AI can perform reliably. The analysts agree. Gartner names agentic AI, software that autonomously handles complex, multi-step service workflows, as one of four core value areas for AI in service, and expects it to autonomously resolve 80% of common service issues by 2029, cutting operational cost by 30%. A product recall claim is a textbook example of the type of process that can benefit from this approach.

The way it should work

Now let us look at the same claim, redesigned to work within an autonomous enterprise. The customer files a claim through the commerce storefront that sold the vacuum, or simply by email. Either way, it arrives as a case in SAP Service Cloud V2. From there, native AI capabilities handle the heavy lifting while a custom Joule agent provides the reasoning that ties the process together.

• It reads the receipt for you. Service Cloud extracts the product, serial number, retailer, and purchase date from the uploaded proof of purchase using SAP's document extraction capabilities.
• It brings together the available context. If the customer previously registered the product, Service Cloud links the product record and warranty information to the case automatically. In a recall, however, many customers purchased through retailers and never registered their products, making the receipt the primary source of evidence.
• Then the Joule agent takes over. This is where reasoning replaces rigid decision trees. Rather than following a fixed sequence of rules, the agent orchestrates the skills needed to resolve the claim.

Eligibility Skill— Does the extracted information satisfy the recall policy? Is it the correct product and batch? Is the serial number valid? Was it purchased within the eligibility window? Is this a duplicate claim? If the evidence is clear, the agent approves or rejects the claim. If confidence is low or the case falls outside policy, it escalates to a human.

Fulfillment Skill— Once approved, the agent creates the return order and replacement sales order in SAP S/4HANA without anyone re-entering the information.

Communication Skill— Finally, the agent notifies the outcome to the customer in plain language. Approved claims receive return instructions, a prepaid shipping label, and replacement details. Rejected claims receive a clear explanation rather than a generic error message.

The entire process completes in minutes rather than days. It scales to thousands of claims without adding headcount, applies the recall policy consistently, and leaves people free to focus on the situations where their judgment truly matters.

Notice what hasn't disappeared: the workflow. The agent still invokes deterministic processes to create orders, trigger fulfillment, and send communications. What's changed is that the agent decides when and how those workflows should be used

Under the hood: Configure what SAP provide, build what makes you unique

The architectural principle applied here is simple: configure what's already productized and build only where your business differentiates itself.

Configured, not coded (native SAP Service Cloud V2)

• Email-to-case intake using standard capability to automatically create a case for an incoming claim email
• Business Information Extraction to read and decipher email content
• Document Extraction using a custom proof-of-purchase extraction schema to read and decipher the attached receipt
• Registered products and warranty lookup
• Customer returns
• Email communications to customers

The one thing we build: The only custom component is the recall claim agent. Built in Joule Studio on SAP Build, it orchestrates three business skills: eligibility, fulfillment, and customer communication. Grounded through SAP's Generative AI Hub in AI Core, it reasons over the extracted data, determines the appropriate outcome, orchestrates the required business actions, and decides when to escalate to a human.

Everything else is already a product capability. Service Cloud manages cases, document extraction, customer returns, and customer communications, while SAP S/4HANA executes the business transactions. The custom agent provides the missing layer: business reasoning. It evaluates the evidence, applies your recall policies, orchestrates the appropriate SAP capabilities, and knows when to involve a person. Our rule is simple: configure the standard solution, build the differentiation.

Zooming in: how we build the agent in SAP Build

Let's zoom in on the custom component. The recall claim agent is assembled in Joule Studio, SAP Build's agent development environment on SAP BTP. What's interesting isn't just that the agent has multiple skills, it's that not every skill relies on AI in the same way. Some require reasoning. Others are deliberately deterministic.

• The agent orchestrates. At the top level, the agent reasons on a model hosted through SAP's Generative AI Hub in AI Core. Its job is to plan the work: decide which skill to invoke next, chain them together, and determine whether the process can continue autonomously or should be escalated.
• Eligibility reasons. This is the decision-making skill. It evaluates the extracted receipt data against your recall policy using Retrieval-Augmented Generation (RAG), grounded on business knowledge stored in AI Core, such as recall policies, valid batch lists, and warranty terms. The outcome isn't simply a yes or no. The agent returns an approval, rejection, or escalation together with its confidence.
• Fulfilment acts. Once a decision has been made, this skill becomes entirely deterministic. It invokes SAP S/4HANA APIs to create the return order and replacement sales order. No language model is involved because this is a transactional business process where predictability and auditability are essential.
• Customer Communication writes. Finally, the agent drafts the customer response using a Generative AI Hub model, grounded on approved brand and policy templates. Data masking and content filtering are applied as part of the AI pipelines before it registers an outbound email activity in Service Cloud to deliver the email

You assemble the solution once by connecting SAP Service Cloud V2 and SAP S/4HANA through SAP BTP destinations, loading the grounding documents into AI Core, and defining the agent's instructions, tools, and guardrails in Joule Studio. From that point on, the platform handles the planning, orchestration, and tool chaining while the underlying SAP applications continue to execute the business transactions.

Show your work: the decision log

Here's the question every risk officer asks, and rightly so: if the agent approved the claim, can it prove why?

That's why the agent doesn't simply decide. It leaves an audit trail. Every autonomous approval writes a timestamped decision log back to the case, recording each eligibility check, its outcome, the evidence considered, the policy version it was grounded on, the confidence threshold it met, and the business actions that followed, including the return order, replacement order, and customer communication.

A business user can open any claim and see exactly why it was approved from the same SAP Service Cloud V2 Case Timeline they already use. The agent records each reasoning step as a custom timeline event through Service Cloud V2's inbound events API, placing it alongside native case updates, linked SAP S/4HANA transactions, and customer communications.

At the platform level, SAP AI Core and the Generative AI Hub maintain their own operational audit records, including model invocations, prompts, orchestration steps, and inference observability. These logs serve a different audience: AI operations, security, and compliance teams responsible for monitoring and governing the AI platform.

Together, these two layers provide complete traceability. The business audit explains what decision was made and why. The platform audit explains how the AI system reached that decision. That’s what makes autonomous execution defensible in a regulated process like product recall. Not blind trust in AI, but evidence that every decision can be understood, reviewed and audited.

Old way vs. agentic — at a glance

Our POV: how we’d approach it differently

• Design for exceptions, not the happy path. Let the agent resolve straightforward approvals and rejections automatically, and route only genuinely ambiguous claims to a human, complete with its reasoning and supporting evidence. Your experts stop rubber-stamping routine work and focus on the cases that truly require judgment.
• Keep the human in control, not in every case. The agent operates within guardrails you define, including confidence thresholds, business policies, value limits, and escalation rules. When a claim falls outside those boundaries, it hands control to a person..
• Govern by design. The agent operates within SAP's identity, authorization, and audit framework, making every action and decision traceable. For regulated processes such as product recalls, that level of governance isn't optional. It's what makes autonomous execution practical in the enterprise.

Autonomous enterprise isn't about removing people from the process. It's about removing people from the repetitive parts of the process, so they can focus on the moments where human judgment creates the most value.

The payoff

What begins as a war room of service agents and a backlog of frustrated customers becomes a quiet, governed, autonomous process. Claims that once took days are resolved in minutes. Operational costs no longer grow in lockstep with claim volumes, and every customer receives the same fast, consistent outcome, whether they're the first claim or the hundred-thousandth.

That's the real payoff of an autonomous enterprise. It isn't simply doing the same work faster. It's allowing people to spend their time where judgment, empathy, and experience matter most, while the routine work happens reliably in the background.