Evolution and Architecture of Meituan's Supply Chain System

1. Supply Chain System Overview

Meituan began as a group‑buying business and later added payment, merchant management, verification, voucher services, and other functions. The supply chain system is responsible for producing and operating goods, where “goods” refer to local life‑service packages, vouchers, and related offerings.

The well‑known “Thousand‑Group Battle” in the group‑buying sector highlighted the importance of strong business development (BD). After BD negotiates with merchants, an account is created on Meituan, contracts are signed, and the agreed items become purchasable on the mobile app or website. The entire process from BD agreement to consumer purchase is handled by the supply chain.

The system’s purpose is to support Meituan’s rapidly growing businesses, and its construction proceeds step by step.

2. Evolution of the Supply Chain System

The architecture is not overly complex; it has evolved alongside Meituan’s growth stages.

2.1 Manual Stage In 2010, the system was a manual, one‑order‑per‑day process modeled after U.S. examples. Orders were uploaded and only visible on the site after seven days, requiring editorial review and dedicated editing staff. This continued until 2011, when leadership decided to increase daily order volume.

2.2 From Online to Automation The goal shifted to 250 orders per day, prompting the creation of a contract and a CMS to replace manual editing. The CMS introduced structured data with three major sections, allowing a single person to handle 11 orders after the workflow was split among three editors.

Facing competition from Dida, Lashou, and Nuomi, Meituan dramatically increased daily order capacity to several thousand, accelerating the time from merchant agreement to online availability.

The core system was rewritten, introducing attribute‑based elements and a template concept that allowed different categories to have distinct attributes. Together with the front‑end, a dynamic form system was built, assigning IDs and values to each attribute, greatly reducing manual editing and page‑beautification work, cutting order‑to‑live time to two days.

By September 2014, daily order volume approached 14,000, with editorial staff reduced from 240 to 10, and most orders went live within a day, cementing Meituan’s leadership in group buying.

3. Transition to Multi‑Business Support

3.1 Platform + Differentiation The industry has rapidly changed; pure group buying can no longer sustain a large company. Competitors have expanded into services such as food delivery (e.g., Ele.me). Meituan responded with Meituan Waimai, breakfast delivery, and vertical services like KTV, hotels, and ticketing, as well as home‑service and discount‑based offerings.

These new lines posed a challenge: how to evolve the supply chain from a single‑business system to one that supports many. The team, now only about a dozen people, needed to move away from a coarse, fast‑iteration approach that ignored internal design.

We analyzed internal systems (delivery, breakfast, hotel) to identify commonalities and differences in order‑processing flows. Differences mainly appeared in process steps and presentation, leading us to define structured variations and optimize them accordingly.

Examples include “lightning order” and “BD order,” where merchants self‑service their listings. Although processes differ, their underlying logic is the same. Our goal is a unified platform with differentiated workflows.

Dynamic forms previously suffered from attribute binding issues when multiple order channels displayed differing values for the same attribute. The new solution separates values into an Attribute Center (AC) and a Dynamic Form (DF). Templates are created per channel, with channel‑specific display items defined for each attribute, which then generate the final entry form.

The CMS also generates pages based on attributes. While keeping the product center highly platform‑oriented, we provide differentiated adaptations—for instance, a KTV ordering system lets merchants define rooms, times, and drinks, while pricing, settlement, and inventory remain product‑centric. The system abstracts away channel‑specific complexities, handling the “dirty work” for downstream services.

3.2 Structure of the Product Center The product center abstracts concepts such as consumption units (e.g., a haircut service) and sales units (e.g., a bundled package of iPhone, earphones, and screen protector). Inventory is managed at the sales‑unit level.

Different business lines (travel, delivery, hotel) can define their own attributes (e.g., opening time, purchase channel restrictions, purchase limits) within this unified product model, enabling the platform to support a wide variety of services.

In this way, any new business can be integrated by providing an AC+DF interface, passing through the defined workflow, and leveraging the existing platform infrastructure.

Source: http://segmentfault.com/a/1190000002952831