Case-to-Resolution: Connecting SAP Service Cloud V2 with S/4HANA Public Cloud

A delivery arrives dented at the customer’s dock. The call hits the service line, the email with photos follows an hour later, and from there many companies start a wandering exercise: the complaint lives in a shared mailbox, the replacement order in an Excel list, the credit note somewhere in accounting. The customer calls three times to find out where his case stands and gets three different answers. That’s exactly the flow we rebuilt for a B2B manufacturer: case in SAP Service Cloud V2, fulfillment in S/4HANA Public Cloud, status back into the case. This post shows what the connection looks like when it’s done cleanly, and which ground rules proved themselves in the project.

Where the Case Lives, Where Fulfillment Lives

The architecture starts with a deliberate division of labour. The case lives in Service Cloud V2. That’s where all channels converge: email, phone, customer portal, everything becomes the same object, the case. That’s also where the case categories sit, the service level agreements with their deadlines and escalations, and the entire communication with the customer. The agent sees at a glance who’s asking, what has already happened and how much time is left before the SLA breach.

Fulfillment lives in S/4HANA. Service order, return, spare-part logistics, confirmation, invoice or credit note: all documents with inventory management, cost accounting and financials behind them. A CRM can’t do these things, and it shouldn’t try. Anyone rebuilding stock levels or billing inside the CRM is building a second ERP, just a worse one.

Two systems, two roles. The integration connects them, it doesn’t blend them.

Master Data First, Process Second

The most common mistake in these projects is the sequence. Everyone wants to build the process flow right away, create the service order from the case, watch the status come back. Except: without synchronised master data, none of that runs. Before any document flows, two things have to be in place.

First, the customers. Accounts in Service Cloud V2 and business partners in S/4HANA have to be the same, with clean ID mapping through the standard replication. Second, the registered products, equipment in ERP terms. The agent has to see in the case which machine, which device, which installation sits at the customer’s site, with serial number and installation date.

Only then does the case get smart: the warranty and entitlement check runs against the S/4 data. Is the device still under warranty? Is there a service contract? Without that connection, the agent guesses or looks it up in the ERP, and both cost minutes on every single case. Master data integration is unglamorous, but it’s the foundation. De facto it decides whether the process integration afterwards takes weeks or months.

The Clean Flow: From Case to Resolution

This is what case-to-resolution looks like when both systems play their role:

1. The case is created in Service Cloud V2, whatever the channel. Call, email, portal entry: everything lands in the same case, linked to the customer and the registered product.
2. The agent categorises and checks. Set the case category, verify warranty and entitlement against the S/4 data, the SLA clock starts now.
3. The follow-up transaction is created in S/4HANA. From the case, the right transaction gets triggered: service order, return or credit memo request, depending on the scenario.
4. S/4HANA fulfills. Pick the spare part, confirm the technician’s work, invoice or credit. The ERP leads, as it always does.
5. The status flows back into the case. The agent sees in the case that the replacement shipment is out or the credit note is posted, and informs the customer from there.

The last point is the one that matters most: customer communication stays entirely in the CRM. The customer has one point of contact, one thread, one history. What happens in the ERP he never sees directly, he learns about it through the case.

Our example scenario, the dented delivery, then runs like this: the call comes in, the case is created with category transport damage, the photos attach to the same case via email. The agent checks the delivery in the linked S/4 document, triggers the return and the replacement shipment, plus the credit memo request in one go. As soon as S/4 confirms the replacement, the update goes out to the customer from the case. One process, one number, no searching.

What Proved Itself in the Project

Keep the case taxonomy small. The temptation is real: build a category tree with forty branches for go-live, one for every conceivable case. The result: agents pick whatever, and reporting becomes worthless. Our rule: five to eight categories at the start, then sharpen after three months based on the real cases. The data itself shows where finer branches are needed.

Connect the telephony. In B2B service, the phone is still the strongest channel. A CTI integration that identifies the caller and pops the customer context onto the agent’s screen while the phone is still ringing saves the first minute of every call, plus the tedious question about the customer number. We’ve built such CTI adapters for Service Cloud V2 several times; the effort is manageable, the everyday effect is big.

And what to leave alone: First, rebuilding the ERP status handling inside the CRM. The case doesn’t need a twin of every S/4 document status, it needs the answer to the customer’s question: in progress, on its way, done. Mirror every document flow and you’ll maintain two status models from then on. Second, double-maintaining product hierarchies. The hierarchy has one home, the ERP, and gets replicated from there. Two hand-maintained hierarchies will drift apart, guaranteed, the only question is when.

What You End Up With

A case that’s traceable from the first call to the credit note. An agent who sees warranty and delivery status without switching systems. A customer who calls once instead of three times. And two systems that stay in the standard, because neither imitates the other’s job.

Frequently Asked Questions

Does Service Cloud V2 replace a separate ticket tool?

For customer-facing service: yes. Omnichannel intake, case categories, SLAs, knowledge base and customer history are on board, and the ERP connection is the real advantage over a generic ticket tool. For internal IT ticketing, a dedicated tool often remains the better choice; that’s a different use case.

Can field technicians work with it?

Yes, for straightforward visits directly with the case and the S/4 service order. Once scheduling gets demanding, with shifts, skills and route optimisation, SAP Field Service Management is the right addition: the case stays in Service Cloud V2, dispatching runs in FSM. The bridge between the two is standard.

What effort is realistic?

If the master data integration is in place, meaning accounts and equipment already replicate, we’re talking weeks for the case-to-resolution flow, not months. The standard integration via SAP Integration Suite covers the document flows. It only gets expensive when the master data is missing or someone builds custom quirks into the status logic.

Your complaints live in a shared mailbox and your service team hunts for delivery status in the ERP? We’ll gladly show you the flow live, with your service processes. Talk to us.