Mobile-First CRM: How intelligentfood Runs Field Sales on SAP BTP

intelligentfood is a fast-growing Swiss beverage and consumer goods company. Its field sales team looks after the indirect sales channels for brands such as El Tony Mate: planning visits, looking after outlets, answering questions on the spot.

When we started, the team had no central mobile app with all the customer data, service information and functions it needed. Visit planning was cumbersome and not based on data. Customer data from the legacy system (Zoro) was not connected to the new ERP, SAP S/4HANA Public Cloud. And the timeline was tight: the new platform had to be live quickly so that sales targets were not put at risk.

TL;DR: We delivered the Sales and Service platform for intelligentfood in three months, over the summer holidays: SAP Sales Cloud V2 and Service Cloud V2 as the core, custom mobile apps on SAP BTP for visit planning, custom views and telephony, and one end-to-end integration with S/4HANA Public Cloud through SAP Integration Suite. The architectural rule that made the speed possible: all custom logic lives on BTP, the CRM and the ERP stay standard.

Project at a glance

Industry	Beverage and consumer goods (FMCG), Switzerland
Starting point	No central mobile sales app; legacy system Zoro not connected to the new ERP
Solution	SAP Sales Cloud V2, SAP Service Cloud V2, custom apps on SAP BTP, SAP Integration Suite
Time to go-live	3 months for the Sales and Service platform
ERP integration	1 end-to-end integration with SAP S/4HANA Public Cloud

The three months refer to the Sales and Service platform described in this post. Spadoom also worked on parts of MM (Materials Management) and SD (Sales and Distribution) in intelligentfood’s Cloud ERP; that is not included in the figure. The full customer story is in our intelligentfood success story.

Why the standard alone was not enough

Sales Cloud V2 was the right core for accounts, contacts, activities, pipeline and reporting, and Service Cloud V2 for service information. What the field team needed on top was specific to how intelligentfood sells:

• Visit planning based on data. Which outlets to visit this week, in which order, and why, instead of planning from memory.
• Custom views. The information a rep needs in front of an outlet is not the same as what a key account manager needs at a desk.
• Integrated telephony on the mobile device. Calls should land in the CRM without the rep typing them in afterwards.

Forcing these requirements into the CRM’s standard configuration would have meant heavy customisation of a SaaS product, with every quarterly release becoming a regression test. So we built them next to it.

How the architecture works

The solution has three layers, each with a clear job.

The core: Sales Cloud V2 and Service Cloud V2. Accounts, contacts, activities, opportunities and service data live here, in the standard. This is the single source of truth for customer data.

The extensions: side-by-side apps on SAP BTP. We built the field-specific functions with the SAP Cloud Application Programming Model (CAP) on SAP BTP, Cloud Foundry runtime: visit planning, custom views and the telephony integration, all available on the reps’ mobile devices. The apps read and write CRM data through the V2 APIs, so everything a rep records ends up on the account in Sales Cloud V2.

The integration: SAP Integration Suite to S/4HANA Public Cloud. A robust connection between CRM and ERP runs over SAP Integration Suite. We also made the necessary configuration on the ERP side, so the end-to-end process works without a media break between sales activities and commercial processes. If you want the design choices behind such an integration in detail, see our Sales Cloud V2 and S/4HANA Public Cloud integration architecture.

Why the ERP side mattered as much as the CRM

Field sales projects are usually discussed as CRM projects. At intelligentfood, much of the risk sat at the seam between CRM and ERP: customer master data, orders and the commercial processes that follow a visit. Because the same team worked on the CRM, the integration and parts of MM and SD in S/4HANA Public Cloud, questions at that seam were answered in one room instead of being passed between two partners. We describe that combination in more detail in SAP S/4HANA Public Cloud and Sales Cloud V2 as an integrated stack.

How the three months were used

The project ran in an agile model with short feedback loops and over the summer holiday period, so decisions could not wait for steering meetings.

• Core systems first. Sales Cloud V2 and Service Cloud V2 were set up in the standard, which kept this part fast.
• BTP apps in parallel. The custom apps were developed alongside the configuration, against the V2 APIs.
• Integration and ERP configuration. The Integration Suite flows and the S/4HANA-side configuration were built and tested end to end.
• Migration and go-live. We migrated the data from Zoro and handled the transition to the new platform.

What changed for intelligentfood

Field sales planned on data. Visit planning is now based on data, and the team has the information it needs at any time in the mobile app, so it can respond to customers faster.

No media break between sales and commercial processes. With the S/4HANA Public Cloud integration, what happens in the field and what happens in the ERP are connected.

Fast value. With go-live after three months, intelligentfood benefited from the new platform early. In the words of intelligentfood’s Head of Sales: “Our team on the street is more effective today than ever before.”

A platform that can grow. Because the extensions run side by side on BTP, new requirements can be added without touching the stable core.

What you can take from this project

Keep the core clean. All custom logic on BTP, CRM and ERP in the standard. Upgrades do not break the extensions, and the extensions do not block upgrades. This was the most important architectural decision in the project. We cover the pattern for the ERP side in our guide to extending S/4HANA Public Cloud with BTP on Cloud Foundry.

Design mobile requirements with the field team. The reps who stand in front of an outlet know which three fields they need. Build for that, not for the desktop.

Plan the ERP integration from day one. A field app that does not know about orders and customer master data in the ERP creates a second truth. The integration is not the last step; it shapes the data model from the start.

---

Need a mobile sales solution that fits how your field team works and is connected to your ERP? We build Sales Cloud V2 projects with BTP extensions and the S/4HANA side with one team. Let’s talk.

Frequently asked questions

Can this approach work for industries other than beverages and consumer goods?

Yes. The pattern (Sales Cloud V2 as the core CRM, custom BTP apps for field-specific workflows, Integration Suite to the ERP) fits any company with a field sales team whose daily work is not covered by standard CRM screens. What changes from industry to industry is the content of the apps, not the architecture.

How long did the intelligentfood implementation take?

Three months for the Sales and Service platform, over the summer holiday period: Sales Cloud V2 and Service Cloud V2, the BTP apps, the S/4HANA Public Cloud integration and the migration from the legacy system. Spadoom’s work in parts of MM and SD in the Cloud ERP is not included in that figure.

Why build on SAP BTP instead of customising the CRM?

Because Sales Cloud V2 is SaaS with regular releases. Side-by-side apps on BTP keep the CRM in the standard, so releases do not break custom code, and the apps can be changed independently when the field team’s needs change.

Which technology did you use for the BTP apps?

The SAP Cloud Application Programming Model (CAP) on SAP BTP, Cloud Foundry runtime. The apps use the Sales Cloud V2 APIs to read and write CRM data, and the connection to S/4HANA Public Cloud runs over SAP Integration Suite.

Did intelligentfood also use SAP S/4HANA Public Cloud?

Yes. intelligentfood runs SAP S/4HANA Public Cloud as its ERP. Spadoom built the end-to-end integration with the CRM, made the configuration needed on the ERP side and also worked on parts of MM and SD.