Greenfield Consumer Goods Cloud Across 4 Geographies

Situation

Suntory Global Spirits, one of the world’s leading premium spirits companies, was replacing manual, spreadsheet-driven sales processes in Korea and Taiwan with Salesforce Consumer Goods Cloud. The engagement was a full greenfield deployment: no existing CRM, no data to migrate, no configuration baseline to iterate from. Every architectural decision would be made from scratch.

The project spanned four geographic centres at once. Client headquarters in Spain directed strategy. Offshore development capacity was split between the UK and India. Two local market teams in Korea and Taiwan would actually use the platform. Each centre had its own priorities, its own interpretation of requirements, and its own understanding of what “done” meant.

The stakes were clear. Consumer Goods Cloud would become the operational foundation for how field sales representatives in Korea and Taiwan managed routes, executed store visits, captured orders, and reported execution data upstream to HQ. If the architecture did not reflect how those markets actually operated, the technology would be rejected at adoption stage regardless of how well it was built.

Challenge

Greenfield deployments present a category of architectural challenge that migrations do not. In a migration, there is a baseline (even a bad one) that defines the shape of the problem. In a greenfield, every design decision is precedent-setting. The data model chosen on day one determines what is possible on day ninety.

Consumer Goods Cloud adds its own complexity. The product is purpose-built for field sales execution: route scheduling, store audit templates, order management, retail execution analytics. But “purpose-built” does not mean “pre-configured.” The standard objects and processes require significant architectural decisions (account hierarchies for retail chains, product catalog structures, visit template design, offline mobile capability) before they resemble a functional field sales platform.

The four-geography coordination problem compounded all of it. Spain HQ held strategic ownership and controlled decisions. UK and India held development capacity and worked across time zones. Korea and Taiwan held operational knowledge: the field reality that no requirements document fully captures. The risk was that architecture would be designed to satisfy HQ requirements, built by offshore teams who had never met a Korean field sales representative, and delivered to users whose actual workflow had never been properly understood.

Scope misalignment in multi-geography programmes does not fail visibly. It fails quietly: a platform that technically works but that field teams do not trust, do not use, and eventually route around.

What I told the offshore team in the first design session

The test of this platform is not whether UAT passes. It is whether the field rep in Busan closes the spreadsheet and opens Salesforce. Everything we design has to earn that.

Action

The first phase was architecture before configuration. Before any Consumer Goods Cloud setup began, the commercial data model was defined: how Suntory Korea and Taiwan conceptualised their account hierarchy (national chains, regional distributors, individual outlets), how products mapped to the sales catalog, what a “visit” meant in operational terms, and how execution data needed to flow upstream to HQ reporting.

This work ran in both directions. From HQ strategy down to define non-negotiable global standards. From local teams up to capture the operational reality those standards had to accommodate. The output was an architecture specification that both HQ and local markets reviewed and signed off before development started.

Consumer Goods Cloud configuration was then built against the specification: account hierarchy, product catalog, route structures, visit templates, order management workflow. Mobile offline capability was configured from the start, because field representatives in both markets worked in retail environments where network connectivity was unreliable.

Every requirement that touched local market operations was validated directly with field teams in Korea and Taiwan. Not via HQ proxies, not via requirements documents, but through working sessions with the people who would use the platform. That captured the operational nuances that top-down requirements processes consistently miss.

User acceptance testing was structured by market, with local team leads signing off on their market’s workflows before acceptance. Training was delivered as workflow-based, role-specific sessions: how a Korean field representative executes a store visit using Salesforce, not how Consumer Goods Cloud works as a product. A structured handoff to local Salesforce administrators in Korea and Taiwan ensured the teams responsible for ongoing support understood the architectural decisions and could maintain the platform without dependency on the project team.

Result

Consumer Goods Cloud was deployed to production across Korea and Taiwan within four months, with zero scope misalignment between the HQ strategic vision and local market execution. All local market requirements were delivered, not as a compromise of global standards, but as a properly architected accommodation of operational reality inside the global framework.

The four-geography delivery coordination produced a platform that field teams in both markets adopted. The real test of a Consumer Goods Cloud deployment is not whether it passes UAT. It is whether field representatives close their spreadsheets and open Salesforce instead. In Korea and Taiwan, they did.

The architecture established a clean digital foundation. No legacy debt, no undocumented customisations, no integration complexity accumulated through years of unplanned growth. Consumer Goods Cloud in these markets is positioned for extension. Agentforce agents that refine route planning, analyse retail execution data in real time, and surface next-best-actions during store visits are technically feasible on this foundation from day one. The architecture was AI-ready before AI capability was on the project roadmap.

Reflection

This pattern works when the market is genuinely greenfield, when HQ accepts that the architecture has to absorb local operational reality, and when a translation function exists between HQ, offshore delivery, and the field. It is the right call when Agentforce or analytics extensions are even on the horizon, because the cost of laying a clean foundation on day one is a fraction of the cost of retrofitting one at month eighteen.

It works less well when the market already has a legacy CRM. The same discipline applies, but the engagement shape is different: the work starts with a migration assessment, not a greenfield design. Pretending the existing footprint can be ignored is the most common way to waste the first sprint.

Worth doing earlier: the direct field validation. The cheapest place to discover that the visit template HQ wants does not match how the rep in Busan actually closes an account is in week three, in a working session, not in week sixteen, in UAT.