Multi-Brand Beauty Group Retail System Architecture: One Architecture, Independent Business Operations

Multi-brand beauty groups often operate multiple retail systems because of their acquisition history. For groups with shared business requirements, continued expansion plans, and no strict requirement for independent deployment, the long-term direction is to consolidate around a unified product foundation. Brand differences can be handled through parameter configuration, interface integration, or necessary customization while keeping business operations separated.

Based on projects involving three brands and twelve brands, this article explains how to evaluate unified architecture, maintain brand boundaries, and plan transition paths.

One brand may mainly operate department-store counters, another may focus on directly operated stores, while a third is entering overseas markets. Even within the same beauty group, their requirements for product attributes, promotion schedules, membership services, channel connections, and store devices may differ.

If every brand builds and maintains its own system, the group must continue to manage duplicated interfaces, inconsistent reporting standards, and multiple maintenance relationships. If all business rules are standardized without distinction, an adjustment made for one brand may affect the others.

This tension can be addressed by placing unification and isolation at different levels:

• The underlying architecture is unified, allowing shared capabilities to be built once and reused continuously.
• Business operations remain separated, with each brand retaining its own products, promotions, membership club, inventory, and store operating rhythm.

1. The Core Tension: Shared Investment, Independent Operations

A suitable architecture must allow both shared capabilities and independent brand operations to exist at the same time. This means the group can reuse common investments without forcing every brand to follow identical business rules.

2. Four Boundaries: What Should Be Unified and What Should Be Isolated

2.1 Metric Definitions: First Agree on How Results Are Measured

To compare the operating results of different brands, a group must first define its key metrics. For example:

• Should sales be measured by payment completion or order creation?
• Should a refund be attributed to the original sales date or the refund date?
• Which cost basis should be used for inventory valuation?

Group-level metrics should clearly define their source systems, reporting periods, calculation methods, and responsible teams. At the same time, each brand should be allowed to retain analytical dimensions that reflect its own business.

Even when some brands continue to use legacy systems temporarily, the group can first establish an explainable view of overall operations.

2.2 Membership Boundaries: Independent Brand Clubs with Separately Authorized Group Reporting

The PEKON CRM & Loyalty Center can configure membership clubs and permissions separately for each brand.

OneID connects stores, mini-programs, e-commerce channels, and Beauty Advisors within the same brand. It does not automatically merge multiple brands under the group into one membership account.

Whether the group can view aggregated membership growth, activity, and repeat-purchase metrics should be confirmed separately according to authorization scope and project requirements.

Membership identities, points, coupons, stored value, and marketing permissions should not be shared across brands by default. For a beauty group, “Can the group view the data in aggregate?” and “Can members use benefits across brands?” are two different design questions.

2.3 Inventory Boundaries: Compare Business Results Without Changing Product Ownership

In the beauty group scenarios discussed in this article, inventory is managed separately by brand, legal entity, warehouse, and store. Inventory transfers between brands are not enabled.

Each brand handles ordering, replenishment, transfers, and stocktaking within its own scope. The group can compare inventory value, turnover, and approaching-expiry metrics, but these aggregated views do not change the ownership of specific goods or the operating responsibility of each brand.

2.4 Technical Isolation: Both a Design Principle and an Acceptance Baseline

Within a unified architecture, it is a basic design principle that an account belonging to Brand A cannot access Brand B’s data. It should also be included as a fundamental acceptance criterion.

Permission testing can verify whether account access has been designed correctly, but isolation testing should not stop at menus and query pages.

Two deeper questions also need to be verified. First, how does the architecture handle brand differences? When a new brand is added or a promotion or channel rule is changed, does the change belong to parameter configuration, interface integration, or customized development? Will special patches continue to accumulate?

Second, does the technical layer follow the same boundaries? Exports, API calls, data synchronization, and background jobs should all be controlled by brand.

Logical isolation, independent instances, and independent deployment address different problems. The appropriate approach should be determined by security requirements, potential fault impact, release arrangements, maintenance resources, and cost. It should not be decided simply by the number of brands.

3. How One Architecture Supports Multiple Brands and Regions

Three Brands, More Than 100 Stores, and an Overseas Flagship Store

A project for a domestic multi-brand beauty group covered three brands and more than 100 stores, including the opening of the group’s first store in Singapore.

The project included connections to local lifestyle platforms, recommended ordering, multilingual operations for overseas stores, promotion configuration, and third-party system integration. More information is available in the public case study about the three-brand retail and overseas flagship store project.

The changes in this project came from both brand differences and market differences. Existing transaction, configuration, and integration capabilities could be reused, while language, channel, and store rules were configured separately.

This reflects the approach of using one unified foundation while configuring brand and market rules independently. Each brand still retains its own operating rules.

Twelve Brands Sharing One Retail Platform

Twelve brands under a US-based premium beauty group shared one retail platform. Each brand maintained its own product, promotion, and membership rules.

The project also connected mini-programs, CRM, and ERP systems. Data that had previously been synchronized every other day was changed to real-time distribution. Online orders that had previously been entered manually were imported automatically. The system also supported store terminals including PCs, iPads, and iPhones.

More information is available in the public case study about the twelve-brand retail collaboration project.

The project reduced repeated data entry, improved the connection between transaction and membership data, and reused the same retail capabilities. The twelve brands shared product capabilities while retaining their own operating rules, demonstrating how unified architecture and independent business operations can work at multi-brand scale.

Extending the Same Architecture Across Regions

Beauty groups may also expand beyond Mainland China. The PEKON team has delivered retail projects in Southeast Asia, and the three-brand project mentioned above verified multilingual operations, promotion configuration, and third-party system integration for a first store in Singapore.

When entering another country or region, language, payment, channel, tax, and invoice requirements still need to be confirmed individually. An implementation result from one market should not be copied directly into another.

Cross-region expansion also requires clear boundaries for data deployment and transfer. Whether membership, order, or employee personal information can be provided overseas, which fields may be transferred, and what procedures apply should be confirmed by the brand’s legal and security teams based on the data type, volume, processing purpose, and relevant regional rules.

A unified architecture can support regional deployment and necessary data exchange, but interface design cannot replace a compliance assessment. Relevant requirements can be reviewed in the Provisions on Facilitating and Regulating Cross-Border Data Flows.

4. Three Paths: Direction, Transition, and Exception

The long-term direction is clear: for groups with significant shared business requirements, continued expansion plans, and no strict requirement for isolated deployment, consolidating around a unified product foundation is generally more suitable.

The other two paths serve as transition and exception options. Each should have clearly defined conditions, migration arrangements, and final responsibilities.

Direction: Unified Product Foundation with Independent Brand Rules

When multiple brands share substantial similarities in store transactions, product management, promotion calculation, permissions, and interfaces, and the group plans to launch new brands, stores, or markets, a unified product foundation can make better use of existing investments.

Brand differences can be handled through parameter configuration, interface integration, or necessary customized development. This avoids binding all brands to identical operating rules and release schedules.

During vendor selection, the group should verify whether rules truly take effect by brand and whether one brand’s configuration, traffic peaks, or version changes can affect other brands.

Transition: Retain Legacy Systems and Start with Group Data Governance

Shortly after an acquisition, when the main brands’ POS, CRM, and ERP systems are still operating reliably and there is no sufficient reason to replace them immediately, the group may retain the existing systems temporarily.

The first priorities can be metric definitions, interface responsibilities, and group-level reporting, with the goal of obtaining comparable data before beginning a broader system transition.

A transition plan should clearly define migration conditions. Otherwise, temporary coexistence may become long-term system accumulation without clear boundaries, increasing interface maintenance and manual reconciliation work.

Exception: Independent Development or Deployment by Each Brand

When brands have clear independent requirements related to security, contracts, regional compliance, or fault isolation, they may develop or deploy systems independently.

The group can still unify selected metrics, interface standards, and governance requirements.

The level of independence should also be clearly specified. For example, the same product can be deployed independently for different brands while continuing to reuse product capabilities, implementation templates, and interface standards.

5. Three Change Tests Before Finalizing the Architecture

First: Add a New Brand

List the organizational templates, transaction capabilities, and interfaces that can be reused. Then list the products, membership rules, promotion rules, and store permissions that need to be configured again.

The key question is whether each difference belongs to parameter configuration, interface integration, or customized development.

If a proposal only says that a new brand can be “copied” but does not explain what must be added, it will be difficult to estimate the actual workload.

Second: Change an Existing Brand

Select a real promotion, approval, or channel requirement. Check who proposes the change, who approves it, how it is released, and how the system can recover if a problem occurs.

During acceptance testing, observe both the target brand and brands that are not involved in the change. This confirms whether the actual impact matches the architecture design.

Third: Retain One Legacy System During the Transition

Select one type of master data and one transaction. Allow the new and legacy systems to complete their respective responsibilities, then test duplicate records, delays, failed synchronization, retry mechanisms, and reconciliation procedures.

A normal demonstration without exception scenarios cannot reveal the actual workload of a coexistence period.

The project scope can be documented by category:

• Standard functions;
• Parameter configuration;
• Interface integration;
• Customized development;
• Temporarily unsupported requirements.

Each item should have a responsible person, deliverable, and acceptance evidence.

The three change tests turn an architecture choice into verifiable project boundaries. Ultimately, the group needs to confirm two things:

• Can the shared components continue to be reused?
• Are each brand’s independent operations clearly protected?

Only when both conditions are met is the architecture suitable for continued brand expansion.

Frequently Asked Questions

Related Reading: Unified Foundations and Beauty Retail Scenarios

To learn more about how shared group capabilities and independent brand operations can be implemented through a unified retail foundation, read How Group Brands Retain Multi-Brand Operating Differences on a Unified Retail Foundation.

For beauty product, membership, store, and multi-brand retail scenarios, visit the Beauty Brand Retail System Solution.

Clarify What This Integration Needs to Solve

Does the group primarily need to address inconsistent reporting, repeated development, the efficiency of adding new brands, or security and regional compliance isolation?

A practical starting point is to list the current objectives, existing systems, brand boundaries that must be preserved, and the three change tests. Business, operations, and IT teams can then evaluate the architecture together.

The long-term direction should be determined by shared business requirements and isolation constraints, while the implementation schedule should reflect the current situation.