You’ve been in this meeting. You know you have.
It starts innocent enough. Someone says, “We need a membership center.” Two requirements, maybe three. Unified member profiles. Tier configuration — regular, gold, diamond. Sounds like a two-week sprint. Sounds like a small module.
Then the meeting starts breathing.
The account person raises their hand: “Which identity is primary — WeChat OpenID, phone number, app account, or store card number? And when someone changes their phone number or merges two accounts, what happens to their tier and benefits?”
Suddenly, “unified member profiles” just swallowed identity authentication and relationship merging whole.
Then operations chimes in: “We need to segment new users, high-value members, and dormant members for targeted campaigns.” The pricing team follows: “Gold members get exclusive pricing — but when member price meets promotional price meets coupons, do we take the lowest, make them mutually exclusive, or stack them?”
Now your membership center has consumed audience tagging, marketing outreach, product pricing, and promotion calculation.
Then the back office arrives. Transactions wants to know how member pricing gets recorded in order snapshots and what happens to growth points and benefits after a return. Finance wants clarity on who books stored value, balance, and benefit costs. Customer service wants to check membership status inside support tickets and manually issue benefits with an audit trail.
Every single requirement was reasonable. Every single requirement was related to membership. And that’s exactly how your system died.
The problem isn’t that there are too many requirements. The problem is that nobody stopped to ask a much more dangerous question: Who owns this?
The Real Disease Isn’t Scope Creep — It’s Ownership Collapse
Here’s what actually happens in most membership system rebuilds: the team keeps adding lines to a feature list because every request has a legitimate connection to “members.” But nobody draws a responsibility matrix. Nobody says, “This is mine, that is yours, and we collaborate on this third thing.”
So everything gets dumped into one system. Not because it belongs there, but because nobody had the courage to draw a fence.
Physical system integration is a technical decision. Responsibility integration is an organizational one. Confusing the two is how products become unmanageable.
A small team or a new business doesn’t need to split into seven separate centers on day one. That’s fine. You can share a codebase, a database, even a backend menu. But you cannot share decision ownership, data truth sources, and accounting responsibility without eventually paying for it in chaos.
Related to users does not mean owned by the membership domain.
Four Words You’re Using Interchangeably (And Shouldn’t Be)
The first reason membership boundaries blur is that four words get thrown around as if they mean the same thing: user, account, customer, and member.
Operations says “these users” and means registered people with accounts. Customer service says “this customer” and means someone who placed an order and left a phone number. Membership operations says “gold member” and means a recognized relationship governed by tier and benefit rules.
They can point to the same human being. They are not the same business object.
Picture someone opening your mini-program for the first time, not logged in, just browsing. At that moment, they’re a user — the system might only know a session ID or device identifier. They authorize WeChat login and bind a phone number. Now the system has an account — a persistent identity with credentials that can be bound, unbound, merged, or recovered. That’s an authentication problem.
They buy something in a store and leave a phone number with an order record. Now they’re a customer — someone with a transaction and service history. But having an order doesn’t automatically mean they’ve entered your membership system.
Only when they agree to join — or are enrolled by a business rule — does the system create a member relationship. That relationship belongs to a specific brand, merchant, or group. It has its own join date, status, tier, growth trajectory, and benefits.
Account solves “how do we keep recognizing you?” Membership solves “what is your relationship with this business?” Confuse those two questions and every downstream decision — merging, tier attribution, benefit sharing, cross-brand logic — starts wrong from step one.
Three Boundary Traps That Will Eat Your Lunch
Trap 1: Account merging does not equal membership relationship merging.
Two phone-number accounts confirmed as the same person doesn’t mean two membership relationships — with their tiers, points, paid qualifications, and used benefits — can be directly summed. The account domain answers “is this the same person?” The membership domain answers “by what rules do we preserve, merge, or terminate two relationships?”
Trap 2: A customer with orders is not automatically a member.
Some businesses use “register to join” or “order to join” rules, so customers and members overlap heavily. But that’s an enrollment rule creating set overlap, not a reason to treat two distinct business objects as identical.
Trap 3: Membership tier is not a global property of a login account.
If a group account connects two brands, a user can be a Gold member of Brand A and not a member of Brand B at all. Tier, benefits, and status belong to a specific membership relationship — not to an account that magically inherits everything everywhere upon login.
What the Membership Domain Actually Manages
Strip away the noise and the membership domain manages one thing: a long-term, operable relationship between a customer and a business.
It can expand into tiers, growth mechanics, benefits, and loyalty operations. But it is not the sum of all customer-facing systems. It has a ceiling, and that ceiling is the loyalty platform — not “everything that touches a user.”
The membership domain’s upper limit is a loyalty and relationship platform. But “related to users” is not the same as “owned by membership.”
Before you configure another tier threshold or add another benefit type, ask yourself the harder question: if you opened your membership center right now, how many features are sitting there simply because someone said “this is related to members” — and nobody pushed back?
That number is your technical debt. And it’s growing every time someone says “just one more feature” without asking who actually owns it.
Draw the line. Or watch your membership system eat everything — including itself.
FAQ
Q: Isn't it faster to just build everything in one system for now and refactor later?
A: No. You can share infrastructure — codebase, database, menus — but you cannot share decision ownership, data truth sources, and accounting responsibility. That debt compounds faster than technical debt because it's organizational. By the time you 'refactor later,' no one remembers who owns what.
Q: How do I actually draw the boundary in practice?
A: Before estimating timelines, build a responsibility matrix: for every requirement, name who is primary owner, who collaborates, and where the data truth source lives. If a requirement touches membership but membership isn't the primary owner, it belongs to another domain — even if the code physically lives in the same system.
Q: But in our business, customers and members are basically the same people. Why separate them?
A: Set overlap is not object equivalence. 'Register to join' or 'order to join' is an enrollment rule that makes two sets overlap — it doesn't make 'customer' and 'member' the same business object. The day you need to handle cross-brand logic, account merging, or benefit reversals after returns, that distinction becomes critical.