88VIP Membership Product

What it was

Turn membership benefits from one-off campaigns into distribution that ops can configure, and partners can join by a standard.

What was stuck

Each benefit drop felt like another campaign: rules went into a brief and the path fell apart when it ended. External supply was one-off, so the pool could not grow. Ops was stuck on configuration, not on creative.

What I did

• Analyzed Taobao claim/redemption data; optimized personalized distribution and multi-pool AB rules; built configurable admin.
• Partnered across Alibaba and externally for benefit exchange; defined onboarding standards to speed collaboration.

Desensitized flow

1. 1

   Benefit supply

   Internal exchange or external onboarding passes standards and rules before entering a benefit pool.

2. 2

   Distribution config

   Ops configures audience, pools, and AB rules in admin—not a code change per campaign.

3. 3

   Claim and redeem

   Consumers claim and redeem; results write back to tune distribution rules.

Outcomes

Ops can change rules without a code change; external benefits enter the pool by standard—not one-off integrations.

• Delivered a configurable benefits distribution system and an extensible open supply platform.

How I talk with engineering

Talk this admin system by domain: access is ops config and consumer claim; application is rules/pools/documents; data must reconcile redemptions; integration consumes membership identity and partner supply—it does not rewrite payments.

How I saw it: Do not ship benefits as another campaign

Appendix

Owned distribution strategy and admin tools, consumer UX, and open-platform standards/partner flows.

What I owned

• Distribution strategy and configurable admin: multi-pool benefits, personalization/AB rules, and the claim–redeem loop on both consumer and ops sides.
• Benefits open platform: partner onboarding standards, collaboration rules, and exchange paths so supply can extend.

What I did not own

• Membership identity and payment ledgers themselves (distribution consumes identity—it does not replace account/payment systems).

Collaboration

• Ops and category teams: align pool rules and campaign cadence, folding one-off drops into configurable strategy.
• Partners: onboarding standards cut one-off integrations; engineering owns the rules engine and admin, product owns bounds and acceptance.

How we split the layers (no stack picks)

• Access: admin portal with role-based menus and permissions—not one UI for every role.
• Application: modules by domain (master data, process, rules, documents)—bound the domains before splitting services.
• Data: master data separate from operational documents, plus audit/logs for traceability.
• Integration: connect to existing ERP / MES / production or commerce systems—do not rewrite shop-floor control or core ledgers.

How to size a separately deployed module

If distribution admin and open onboarding deploy separately, size by ops-config concurrency, claim peaks, and redemption-reconciliation volume. Core/RAM are an engineering load-test call.

• Stateless apps: size instances by admin-seat count and peak concurrency; scale out. Ask “who is on at once” before asking for a machine SKU.
• Database: document volume and whether reporting contends with writes decide read replicas or a separate reporting store.
• Files and logs: attachments, exports, and audit trails should not live only in the OLTP database.
• A separately deployed mid-size admin module is usually app instances + database + needed middleware. Spine vs edge modules differ by a tier. Core/RAM are an engineering load-test call; product states availability, permissions, audit, and order-of-magnitude volume.