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 infrastructure, no data to migrate, no baseline configuration to iterate from. Every architectural decision would be made from scratch.

The project spanned four geographic centers simultaneously: Client headquarters in Spain directing strategy, offshore development capacity split between the UK and India, and two local market teams in Korea and Taiwan that would actually use the platform. Each center 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 headquarters. If the architecture didn’t 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 don’t. 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 you choose on day one determines what you can and cannot do 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, and retail execution analytics. But “purpose-built” doesn’t 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 this. 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 captured. 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 was never properly understood.

Scope misalignment in multi-geography programs doesn’t fail visibly. It fails quietly: a platform that technically works but that field teams don’t trust, don’t use, and eventually work around.

Action

Architecture Definition and Commercial Workflow Design

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 conceptualized 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 was done in both directions — from HQ strategy down to define non-negotiable global standards, and from local teams up to capture the operational reality that global standards had to accommodate. The output was an architecture specification that both HQ and local markets had reviewed and agreed to before development started.

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

Cross-Continental Delivery Bridge

The structural delivery risk was the gap between HQ decision-making and local market reality, mediated by an offshore development team that was remote from both. The role I played was the translation layer: converting HQ strategic directives into development specifications that were technically unambiguous, and converting local market operational requirements into scope that HQ would approve.

This required operating in three time zones simultaneously and maintaining alignment across stakeholders who had conflicting priorities. When HQ pushed for a standardized global visit template, local markets pushed back with legitimate operational differences. When offshore development interpreted requirements ambiguously, local market testing surfaced the gap. The architecture function was to absorb these conflicts before they became delivery failures.

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. This captured the operational nuances that top-down requirements processes consistently miss.

Deployment and Handoff

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 the local Salesforce administrators in Korea and Taiwan ensured that the teams responsible for ongoing support understood the architecture 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 within the global framework.

The four-geography delivery coordination produced a platform that field teams in both markets adopted. The test of a Consumer Goods Cloud deployment isn’t whether it passes UAT — it’s whether field representatives close their laptops and open Salesforce instead of a spreadsheet. In Korea and Taiwan, they did.

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

Technologies used: Salesforce Consumer Goods Cloud, Salesforce Mobile (offline-first configuration), Sales Cloud, standard and custom record types, visit template engine, route management, mobile offline briefcase configuration