Industry Insights 13 min read

How Youzan Unified Its Customer Operations Platform: From Silos to a Scalable Architecture

This article analyzes Youzan's transition from fragmented, silo‑based customer‑operation services to a unified, component‑driven platform, detailing the early challenges, the strategic integration decisions, the technical architecture, and future directions for scalable business operations.

Youzan Coder
Youzan Coder
Youzan Coder
How Youzan Unified Its Customer Operations Platform: From Silos to a Scalable Architecture

1. Introduction

Youzan is a merchant‑service company that helps businesses privatize customer assets, expand online reach, and improve operational efficiency. Key performance indicators such as acquisition, retention, activation, and conversion have become increasingly costly, driving stronger demands for precise customer operations.

2. Early “Silo” System Construction

Initially, each new customer‑operation product (interest‑group marketing, interactive fan marketing, precise‑group marketing, birthday marketing, holiday marketing, member‑day marketing, etc.) was built as an independent “chimney” following a traditional IT workflow: product proposes requirements, technical teams analyze, develop, test, and launch.

This approach led to duplicated functionality, long integration chains, high maintenance costs, and slow iteration because every new feature required a fresh implementation.

Repeated investment due to duplicated development and maintenance.

High integration and collaboration costs between siloed systems.

Hindrance to business knowledge accumulation and technical evolution.

3. Integration Opportunity

During the annual spring product launch, Youzan decided to upgrade fan management into a full‑channel membership marketing center, incorporating “scene marketing” and “group operations.” Rather than retrofitting the existing system—an effort that would increase scope, complexity, and cost—the team chose to build a new system and consolidate existing business logic.

4. System Construction

4.1 System Goals

Integrate underlying capabilities of scene marketing and group operations into a unified domain model for easier maintenance.

Atomize functions into reusable components, enabling configuration‑driven extensions via workflow orchestration.

Establish a customer‑operation middle platform that exposes scenario‑based APIs for micro‑mall, retail, and future business forms.

Provide a foundation that accelerates product iteration, allowing most new features to be realized through configuration or plug‑in extensions.

4.2 Commonality and Variability Analysis

Analysis of six existing products revealed shared concepts: operation object, operation time, operation behavior, and user operation records. The core idea of an operation plan is to select a set of targets, define a suitable time window, and execute specific actions.

Variable dimensions identified:

Operation Object: tiered members, birthday members, public‑account followers, browsers without purchase, cart‑abandoners.

Operation Time: periodic (daily, weekly, monthly), birthday (day/week/month), fixed windows, immediate, delayed.

Operation Behavior: grant rights (points, coupons, free‑shipping, discounts), send notifications.

User Operation Record: rights granted, notifications sent, rights used, rights replenished.

4.3 Technical Architecture

Core Domain Model: The “operation plan” domain model abstracts and implements the central business logic.

Foundational Components: Generic, domain‑agnostic modules such as task handling, flow control, notification, and cron‑like expression processing, reusable across products.

Business Products: Specific offerings (birthday marketing, holiday marketing, member‑day marketing, precise‑group marketing, interest‑group marketing, interactive fan marketing) built on top of the core model.

Scenario Aggregation Layer: Implements scenario‑specific APIs for micro‑mall, retail, and other front‑ends, enabling reuse.

Front‑End: Various Youzan industry‑specific products (micro‑mall, retail, chain retail, etc.) consume the unified back‑end.

4.4 Operation Time

Operation time is highly variable; therefore a custom “period expression” component was created based on cron syntax:

Weekly on Monday and Wednesday: * * * * * 1,3 * 32 Daily fixed window 08:20‑20:30: * 20-30 8-20 * * ? 31 Fixed date range 2019‑04‑24 to 2019‑04‑25: 0-0 0-0 0-0 24-25 4-4 * 2019-2019 2 Operation time is further split into effective time, operation period, and execution time, with future interfaces to abstract their calculations.

4.5 Unified Audience System

The existing SCRM audience system, though simple, is designated as the single source for “circling” rules and filters, allowing future expansion of audience dimensions and reducing duplicated logic.

4.6 Unified Rights Platform

Current group‑operation products only support coupon distribution. By integrating the rights platform, the system gains access to dozens of rights types (free‑shipping, discounts, points, multipliers, vouchers, gifts, experience cards, growth values, etc.) and underlying capabilities such as multi‑version rights, inventory, periodic rights, issuance, and reclamation.

This integration lets the customer‑operation system focus solely on “when and to whom” to grant rights, delegating the details of rights issuance to the platform.

4.7 Task Processing

The new system adopts a streaming approach with three steps: split, load, execute, improving overall task throughput. Dynamic throttling prevents downstream overload, and a distributed batch‑processing scheduler (TSP) handles delayed and timed tasks, with automatic retries for failures.

5. Outlook

The revamped customer‑operation platform leverages existing SCRM capabilities while driving the evolution of dependent subsystems. Future work includes building digital operation analytics, adopting a metadata‑driven product model to accelerate new feature delivery, and creating a business audit platform for stability and risk control.

Overall, the architecture emphasizes business value, holistic decision‑making, and avoids premature generic design that could lead to architectural traps.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

System ArchitectureMicroservicescustomer operationsPlatform Integrationbusiness scalability
Youzan Coder
Written by

Youzan Coder

Official Youzan tech channel, delivering technical insights and occasional daily updates from the Youzan tech team.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.