We Run SAP Sales Cloud and Service Cloud Ourselves. Here Is What We Built.

We spend a lot of time telling customers not to build CRM theatre.

No giant first phase. No endless workshops. No custom fields because someone once saw them in an old system. Start with the work. Build the process. Go live. Improve from there.

So when we decided to run SAP Sales Cloud V2 and SAP Service Cloud V2 for Spadoom itself, we had to take our own medicine.

We licensed the stack at the beginning of 2026. About a month later, we were live.

The Scope

We kept the first release deliberately small.

For sales, the core process was clear:

• Capture leads from real conversations, events and the website.
• Manage accounts and contacts cleanly.
• Track opportunities without turning every deal into an admin project.
• Keep follow-ups visible.
• Give management enough pipeline context without building a reporting monster.

For service, the requirement was just as practical:

• Track support requests as cases.
• Keep ownership clear.
• Connect incoming website requests to the support process.
• Make status and next action visible.
• Avoid losing customer context in email threads.

That was enough for go-live. Everything else had to earn its place.

Why Sales Cloud V2

SAP positions Sales Cloud as CRM for sales execution: lead and opportunity management, account work, guided selling, forecasting and analytics. That is the public promise.

Our internal question was simpler: can our team see what matters without digging?

We configured Sales Cloud around how Spadoom sells. We rarely have a transactional sales motion. A first conversation often includes architecture, integration, product fit and uncomfortable questions about scope. The CRM needs to support that reality.

So we focused on clean account structure, useful opportunity stages, clear next steps and enough qualification detail to avoid repeating the same conversation twice.

Why Service Cloud V2

SAP positions Service Cloud around service operations: case management, knowledge, automation and customer support processes.

For us, the key object is the case. A support request needs a home. It needs an owner. It needs a status. It needs context.

Before this project, too much support work could still happen in places that are easy to lose: inboxes, chats, side notes. That works when volume is low. It starts to hurt when more customers, more projects and more handovers appear.

Service Cloud gives us one place to manage that work.

The Website Connection

The website matters because it is often the first place a support request or sales signal appears.

We connected website submissions to the internal process so requests can move into SAP Service Cloud instead of sitting in a mailbox. The point is not technical glamour. The point is basic operational hygiene:

• The request gets captured.
• The right team can see it.
• The status can be tracked.
• The history stays with the customer.

That is exactly the kind of integration we recommend to customers. So we built it for ourselves.

What We Personalised

We did not implement a generic SAP demo tenant.

We adapted the system to how Spadoom works:

• Opportunity stages that match consultative SAP CX deals.
• Case categories that reflect real support work.
• Lean fields for fast entry instead of decorative completeness.
• Views for the people doing the work, not for a slide deck.
• Website-connected intake for support requests.

This is where many CRM projects go wrong. They either stay too generic and nobody adopts the system, or they customise everything and create a maintenance problem.

The useful path sits in the middle: adapt the process where it matters, stay standard where it does not.

What We Learned Again

This project confirmed what we see in customer projects.

First, speed comes from decisions. The product was not the bottleneck. Scope discipline was the key.

Second, standard configuration goes further than people expect. You do not need to customise every irritation away in release one.

Third, Service Cloud becomes useful when cases become the default home for support work. If people still run support from inboxes, the system stays decorative.

Fourth, using the system ourselves changes how we advise. We feel the small workflow details every day. That makes our recommendations sharper.

The Technical Shape

The project was intentionally clean:

• SAP Sales Cloud V2 for leads, accounts, contacts and opportunities.
• SAP Service Cloud V2 for case-based support tracking.
• Website intake connected to the support process.
• Standard configuration first.
• Personalisation where it improved daily work.
• Future extensions kept separate from the first go-live scope.

No ceremony. No transformation theatre. Just a working system.

Why This Is Rare

Plenty of SAP partners sell SAP CX. Fewer run their own sales and service operation on the same products.

That matters. When we talk about adoption, fields, service queues, lead quality, handovers or website intake, we are not only talking from customer projects. We are talking from our own daily system.

It is harder to hand-wave when you use the product yourself.

Sources

• SAP Sales Cloud overview
• SAP Service Cloud overview
• SAP Business Technology Platform overview

The Bottom Line

We went live about a month after licensing. Fast, yes. But the more important part is what happens after go-live.

The system now supports our sales and support work every day. It gives us a cleaner pipeline, a better support queue and a sharper view of customer context.

Eat your own dog food, they say.

We do. And then we improve the recipe.