Multi-Brand Beauty Retail in China: Centralized Governance with Independent Brand Operations

Multi-Brand Beauty Retail in China: Centralized Governance with Independent Brand Operations

For a multi-brand beauty group, retail-system design requires a balance between centralized governance and independent brand operations. The group may want to reuse technology platforms, security standards, interfaces, organizational structures, and management reporting, while each brand still needs control over its own products, pricing, promotions, loyalty program, inventory, store operations, and customer relationships.

This article is intended for group CIOs, regional IT teams, retail operations leaders, and China management teams evaluating how to support group-scale retail operations without forcing every brand into the same operating model.

The key question is not whether all brands should use one system or separate systems. It is which capabilities should be standardized at group level, which data and operating rules should remain brand-specific, and how headquarters can obtain a comparable management view without interfering with each brand's day-to-day operations.

What Is a Multi-Brand Federated Architecture?

In this article, a multi-brand federated architecture means sharing a common technology foundation while separating brand-level operating domains and applying governance at multiple organizational levels.

The group establishes common organizational structures, minimum data standards, interface specifications, security controls, and reporting definitions. Each brand then operates within its own domain, managing its own products, stores, prices, promotions, loyalty rules, inventory, and operating teams.

Group management receives authorized summary metrics, operating status, and audit information. Brand teams continue to manage the detailed business rules required for their positioning, channels, and customer segments.

A federated architecture does not mean that all data should be combined. A workable model must first answer four questions: who owns the data, who can view it, who can change it, and who is responsible when an exception occurs.

What Should the Group Reuse, and What Should Each Brand Manage Independently?

A practical starting point is to create a reuse-and-isolation matrix before discussing specific software functions.

This matrix should not be defined by IT alone. Retail operations, merchandising, CRM, supply chain, finance, legal/privacy teams, and brand leaders should participate because many decisions about reuse and isolation are ultimately business, customer-data, or settlement decisions.

1. Organization and Permissions: Group Visibility Without Unrestricted Brand Access

Multi-brand management starts with organization and permissions. The system architecture needs to represent relationships among group entities, legal entities, business units, brands, regions, channels, stores, and department-store counters.

Group management may need authorized access to consolidated performance across brands. A brand general manager should normally see only the relevant brand. Regional managers should be limited to their assigned areas, while store employees should operate only within their store responsibilities.

Access control should therefore extend beyond whether a user can open a menu. It should determine which brands, stores, and fields the user can view, and whether they can create, approve, export, or modify data.

For example, group management may review aggregate member growth by brand without automatically gaining access to customer-level details. Group audit teams may review price overrides, returns, and inventory adjustments without receiving permission to configure promotions.

Before implementation, the group should document the real organization tree and permission matrix rather than simplifying the model into only “headquarters, store, and employee.”

2. Product Standards Should Support Comparison Without Removing Brand Differences

A beauty group can define common product coding principles, core classifications, required fields, and interface standards so that data from different brands can be compared.

However, beauty categories require different product structures. Skincare may focus on specifications, ranges, batch numbers, and expiry dates. Color cosmetics require shades, sets, samples, GWP, and testers. Fragrance brands may need volume, gift-set, and display-product attributes.

Even when two brands sell similar products, they should not automatically share the same SKU simply because the product names appear similar.

A clearer model is to separate common group fields from brand extension fields. The group can define mandatory attributes such as brand, category, specification, unit of measure, and status, while individual brands maintain shade, range, customer segment, GWP attributes, tester rules, and other category-specific information.

3. Pricing and Promotions Can Reuse Technology While Rules Remain Brand-Specific

A beauty group may reuse common promotion technology, approval structures, and risk controls, but each brand should retain control over its own price lists, discount ranges, campaign thresholds, GWP policies, loyalty offers, and channel rules.

A premium skincare brand may restrict public discounts and focus more on loyalty gifts, appointments, and high-touch services. A mass-market brand may run frequent threshold discounts, bundles, and GWP campaigns.

Department-store counters add another layer. In China, beauty brands often operate counters inside department stores where mall campaigns, department-store coupons, centrally collected payments, commission deductions, and end-of-day settlement may interact with the brand's own promotion and POS processes.

The group can define approval and audit requirements, but it should not automatically decide the commercial rules for every brand. Before a campaign is released, the applicable brand, product, store, member segment, and channel should be explicit.

4. Loyalty Should Remain Brand-Owned Even When the CRM Platform Is Shared

Loyalty is one of the areas most likely to be misunderstood in a multi-brand architecture. Using one CRM technology platform does not mean that all brands should be merged into one loyalty club.

Premium skincare, professional makeup, fragrance, and mass personal-care brands can have very different audiences, price points, service models, and communication frequencies.

In many multi-brand beauty groups, each brand therefore maintains its own member profiles, tiers, points, coupons, stored-value arrangements where applicable, marketing permissions, and engagement rules.

Group-level value comes primarily from platform reuse and governance: common technology architecture, security controls, audit mechanisms, integration monitoring, and reusable implementation templates.

Group management may review authorized aggregate indicators such as member scale, growth, activity, and repurchase, while detailed member operations remain with the individual brand.

The boundary of OneID should also be explicit. Within PEKON's architecture, OneID can connect a single brand's customer identity across stores, WeChat mini-programs, e-commerce channels, and associate touchpoints. In a multi-brand implementation, customer identities and loyalty benefits remain configured and managed by brand unless a separate cross-brand business model, authorization framework, and system scope are explicitly agreed.

5. Group Inventory Visibility Is for Capital and Risk Management, Not Automatic Cross-Brand Transfers

Group management may want a consolidated view of inventory by brand, region, and store. The purpose is usually to understand working capital, inventory health, and operating risk rather than to transfer goods freely between brands.

Beauty brands normally maintain separate products, inventory ownership, costs, and channel structures. The retail platform should therefore emphasize brand-level inventory isolation, group-level comparison, and replenishment or transfer processes within each brand.

Useful group-level questions include:

• How much working capital is tied up in inventory by brand?
• Which brands have higher stockout, slow-moving, or near-expiry risk?
• Where are abnormal stocktake differences appearing?
• Are samples, GWP, testers, and damaged goods being incorrectly counted as sellable stock?

Group reports can compare inventory-health indicators across brands, while replenishment, store transfers, promotion-driven clearance, and returns remain the responsibility of each brand.

Where several brands use the same physical third-party warehouse, physical location may be shared while inventory ownership remains separate. The project should define brand-level stock ownership, warehouse zones or logical separation, movement responsibility, and reconciliation rules.

6. Multiple Brands in the Same China Department Store Still Need Brand-Level Operations

A beauty group may operate several brand counters in the same department store or shopping mall. Group-level involvement in channel negotiation, contracting, or resource allocation depends on the actual organization and contracting model.

Product, pricing, promotions, inventory, beauty advisor (BA) performance, and member services normally remain attributed to each individual brand.

The retail architecture should clearly represent the relationship among brand, region, department store, store, and counter so that sales, returns, mall campaigns, inventory, and BA performance are assigned correctly.

China department-store projects may also involve centrally collected payments, later entry of sales transactions, mall coupons, commission deductions, and settlement reconciliation. The project should define which system records the sale, which party collects payment, where mall coupons are redeemed, and which system owns final settlement.

Group management can compare sales performance across brands operating in the same department store, but the retail platform should not be presented as a replacement for the department store's settlement system or the group's finance system.

7. Group Reporting Requires Common Definitions and Brand-Level Explanation

Group reporting cannot be built by simply adding together existing brand reports. Even apparently simple metrics such as “members,” “active members,” “store sales,” “GWP cost,” and “inventory turnover” may be calculated differently by different brands.

The group should first create a metric dictionary for cross-brand comparison, including data source, calculation period, organizational scope, return treatment, and update frequency.

Group users can then drill from consolidated indicators into business unit, brand, region, channel, or store according to authorization. Brand teams can continue using more detailed product, campaign, member, and BA reports that reflect their own operating models.

A useful group dashboard should help answer questions such as:

• Is brand growth coming from new stores, comparable-store growth, or promotions?
• How do stockout rates, inventory health, and near-expiry risk compare across brands?
• Can member growth, activity, and repurchase be translated into comparable group metrics while retaining brand-specific operating definitions?
• Which interface failures, system exceptions, or store operations require group attention?
• Has a newly added brand adopted the group's required data standards?

Financial consolidation, foreign-exchange rules, and tax definitions should remain the responsibility of group finance or specialist finance systems. The retail platform can supply transaction and operating data but should not replace formal financial-consolidation rules.

8. New Brands Should Reuse Mature Foundations Without Copying Existing Brand Rules

The value of a group platform becomes particularly visible when the group acquires, incubates, or introduces a new brand.

Instead of rebuilding POS, CRM, interfaces, roles, and reporting from the beginning, the group can reuse suitable templates for organization structure, store master data, payment methods, basic inventory processes, integration standards, access roles, and reporting frameworks.

The new brand can then configure its own product attributes, pricing, promotions, loyalty club, BA processes, and channel integrations.

Reusing a template does not mean copying existing business data. Before launch, the project still needs to address historical products, members, points, inventory, open orders, store accounts, and migration or archive requirements.

Pilot stores should validate sales, returns, loyalty benefits, inventory, and end-of-day reconciliation before wider rollout.

The relationship between a standard platform and brand-specific requirements should also be documented. Each requirement should be classified as a standard capability, project configuration, integration, or platform extension rather than being described broadly as “supported.”

Seven Scenarios to Validate During Vendor Evaluation

Multi-brand capability should not be evaluated simply by checking whether the administration screen contains a “Brand” field.

A group can prepare two test brands and two stores and ask vendors to demonstrate the following scenarios using realistic but de-identified data.

1. Organization and Data Isolation

A group administrator can view both brands, while Brand A administrators cannot view or export Brand B products, members, or orders.

Warning sign: separation relies only on hiding menu items while exports or APIs can still expose group-wide data.

2. Independent Promotions

Brand A creates a GWP campaign for selected stores. Brand B POS should not receive or execute the campaign.

Warning sign: campaigns can only be published group-wide and depend on repeated manual store selection to prevent cross-brand impact.

3. Independent Loyalty Programs

Register the same test mobile number separately with two brands. Membership profile, tier, points, coupons, stored-value rules where applicable, and marketing permissions should remain independent by brand.

Warning sign: the system automatically merges the two brand accounts or a change in one brand affects the other brand's tier, points, or communication preferences.

4. Inventory Isolation

Group users can compare inventory and turnover indicators across both brands, while each brand's full-size products, samples, GWP, testers, and other stock remain assigned to the correct inventory domain.

Warning sign: non-sellable items are included in sellable inventory, or brand isolation exists only as a report filter rather than in product, warehouse, and store ownership.

5. Department-Store Counters

Where two brands operate counters in the same department store, validate mall campaigns, centrally collected payments where applicable, sales-entry processes, coupon redemption, inventory, and BA performance by brand.

Warning sign: the system can model only a conventional directly operated store and cannot represent department-store, counter, payment-collection, or later sales-entry relationships.

6. Group Reporting

Group sales can be drilled down by brand and store, key metrics have documented definitions, and brand users see only their authorized scope.

Warning sign: metrics with the same name show different values in brand and group reports without a traceable explanation.

7. Adding a New Brand

Create Brand C using an approved group template while retaining independent product fields, loyalty rules, permissions, and workflows.

Warning sign: adding a new brand requires extensive redevelopment of the base platform, or changes for Brand C unexpectedly affect Brands A and B.

Five Decisions to Make Before Building a Multi-Brand Retail Platform

Before implementation, the group should document at least five decisions.

1. Organization and legal-entity boundaries: define how group, business unit, brand, legal entity, region, channel, and store relate to one another.
2. Reuse and isolation matrix: identify which technologies, interfaces, and reporting capabilities can be reused and which product, member, inventory, promotion, and BA data must remain brand-specific.
3. Master-data responsibility matrix: define which system creates, changes, and distributes each data domain and which system prevails when inconsistencies occur.
4. Permission matrix: define which roles can view, configure, approve, modify, or export information for each brand.
5. Integration and exception mechanism: define synchronization frequency, retry, reconciliation, manual correction, monitoring, and accountable teams.

These decisions are more important than simply purchasing a larger software platform. A federated architecture works only when management boundaries are translated into executable organization, data, access, integration, and process rules.

FAQ

What is a multi-brand federated architecture for a beauty group?

It is an architecture in which multiple brands reuse a common retail technology foundation, selected data standards, and technical capabilities while managing product, pricing, promotions, loyalty programs, inventory, and permissions independently by brand.

The group gains consolidated management, system governance, and audit visibility, while brand teams retain the operating independence required for their markets and customer segments.

Will using one retail platform make every brand operate in the same way?

Not necessarily. Organization structures, integration standards, promotion technology, security controls, and reporting frameworks can be reused while product attributes, price lists, campaigns, loyalty tiers, points, GWP rules, and store-service processes remain brand-specific.

Vendor evaluation should test actual isolation between brands rather than only confirming that the system contains a brand field.

Should loyalty programs from different brands be merged?

In many beauty groups, loyalty programs remain independent because customer segments, price points, service models, and communication strategies differ by brand.

Multiple brands can reuse the same CRM technology platform while maintaining separate member profiles, tiers, points, coupons, benefits, and marketing permissions. Cross-brand benefits should be treated as a separate business and data-governance decision rather than assumed as the default.

What should group management do with consolidated inventory visibility?

Consolidated inventory data is mainly useful for comparing working capital, turnover, stockout rates, slow-moving inventory, and near-expiry risk across brands.

It does not mean inventory should automatically be transferable between brands. Stock ownership, product identity, warehouse responsibility, and reconciliation should remain clear by brand.

What needs to be considered when several brands operate counters in the same China department store?

The project should first confirm the actual relationship among group, brand, and department store, including contract entity, payment collection, commission or concession settlement, and reconciliation.

Each counter's products, pricing, promotions, inventory, member services, and BA performance should remain attributable to the correct brand.

How should group reporting balance consolidation with brand-level analysis?

Start with a common metric dictionary for sales, members, inventory, and promotions, including source systems and calculation rules. Group management can then compare brands using consistent definitions, while individual brand teams retain more detailed operational reporting for their own business.

Do we still need a multi-brand retail platform if the group already has ERP and CRM?

The first step is to assess whether the existing architecture can support brand-level store transactions, promotion execution, inventory operations, loyalty benefits, and organizational permissions.

Existing ERP, CRM, OMS, WMS, and e-commerce systems do not necessarily need to be replaced. The priority is to define systems of record, integration direction, exception handling, access boundaries, and reconciliation responsibilities.

How should a newly acquired or incubated brand join the group platform?

Reuse suitable group templates for organization, payment methods, basic inventory workflows, interfaces, roles, and reporting. Then configure the new brand's own products, prices, promotions, loyalty program, BA processes, and channel requirements.

Historical products, member data, points, inventory, open orders, and store accounts should be assessed separately for migration, retained inquiry, or archive.

Centralized Governance Should Create Reuse, Not Remove Brand Independence

The goal of a multi-brand beauty retail platform is to reuse the technology and governance capabilities that genuinely benefit the group while keeping clear boundaries around each brand's products, promotions, loyalty program, inventory, customer relationships, and store operations.

PEKON's multi-brand architecture can draw on the Pekon Smart Retail System, Pekon Omnichannel CRM & Loyalty Platform, Pekon B2B Ordering Platform, Pekon WeChat Mini-Program Suite, and Pekon Jingang Low-Code PaaS according to project requirements.

The objective is not to require every brand to activate the same products or use the same configuration. The appropriate product combination, data scope, integration design, and level of configuration should be determined according to the group's existing ERP, WMS, CRM, OMS, e-commerce systems, and operating model.

Specific capabilities depend on the applicable product version, configuration, integrations, platform extensions, and agreed project scope.

For groups moving from a single-brand structure toward multi-brand operations, a practical starting point is to define the organization boundary, reuse-and-isolation matrix, master-data responsibilities, and permission model before evaluating the platform through realistic scenarios.

Related English Content

• PEKON Beauty Retail Solution
• A U.S.-Based Luxury Beauty Group — Customer Story

Specific product capabilities, configuration methods, data boundaries, and integration responsibilities should be confirmed against the applicable product version and agreed project scope.