01 layer
knowledge
what it reads before it writes anything
03 playbooks
—
stands on its own
04 next
—
end of the chapter
We have built and rebuilt platforms for direct sales companies for over a decade: Stella & Dot, Juice Plus+, Norwex. Every one of those engagements started the same way, with an engineer looking at an order table and asking why a single order needs four different people attached to it.
The answer is the business model. You cannot design the schema, scope the migration or write a useful ticket until you understand it, and it is not the model most engineers have in their heads from working on retail.
Retail, and then not retail
In retail, a brand like Nike sells through its own stores or through a retailer that carries many brands. Customers walk in and buy. Service ends at sizing help. To get people through the door the brand buys attention: TV, billboards, ads. That spend is in the price of the shoe.
A direct sales company has no stores and no retailers. It sells through a network of independent consultants, and it spends its marketing budget on recruiting and supporting those consultants rather than on reaching customers. The consultants reach the customers.
A customer can still find the products and order directly from the company. But the consultant relationship is the point, and almost every rule in the system exists to protect it.
How a consultant earns
A product that retails at $100 costs a consultant $65. The $35 difference is their commission. They buy at that price for themselves too, which is why the line between a consultant and a heavy customer is blurry, and why your data model probably needs a person to be both.
Commissions are paid out as cash into a bank account. For many consultants this is real income, part-time or full-time, and that has an engineering consequence worth internalising early: commission calculation is a payments system. It is not a reporting feature. It has to be correct, auditable, and explainable to the person receiving the money.
Money is not the only motivator. Most consultants join because they use the products and believe in what the company is doing. It shapes what they will tolerate from your software, which is more than you would expect, and what they will not, which is anything that touches their earnings.
Parties
A consultant can sell one to one, but the mechanism that actually moves volume is the party. A consultant, or a hostess who invites her own circle, gathers a group. The consultant demonstrates the products and takes orders from the group.
Parties run offline in someone's living room and online over Facebook Live and similar. Either way the economics come from borrowing the host's social network rather than the consultant's.
For the platform this means orders arrive in bursts attached to an event, an event has a host who earns rewards based on its total, and the host is usually not the consultant. Retail checkout assumes one buyer and one basket. Party checkout does not.
Downlines
Consultants recruit other consultants. Whoever they recruit joins their downline; the recruiter is the upline.
Commissions flow from personal sales and from downline sales, which is what makes recruiting worth a consultant's time.
This tree is the single most consequential structure in the system. It is deep, it changes as people join and leave, and commission runs walk it on a schedule against rules that finance owns and engineering did not write. Query it naively and it will be the slowest thing in your platform.
Attribution
Every order belongs to a consultant, because a consultant's income depends on it. Usually the customer has a preferred consultant and the attribution is obvious.
The interesting case is the order that arrives with no consultant attached, through the corporate site or a corporate account. Somebody still has to be credited. Companies resolve these with an assignment rule of their own design, often based on the customer's location or on how active nearby consultants have been.
Whatever the rule, it is a fairness policy expressed as code, and consultants will notice when it misfires. Expect to explain it, expect it to change, and do not bury it in a stored procedure.
Becoming a consultant
There is no required path from customer to host to consultant. Someone who already likes the products can sign up directly and start at consultant pricing.
Enrollment is therefore a conversion funnel, not an admin form, and it is one of the two numbers the business watches.
The two numbers
Growth in direct sales comes down to:
- how fast new consultants are recruited
- how many parties get hosted
Everything else is downstream. When you are prioritising work on one of these platforms and need a tiebreaker, ask which of those two numbers the change moves. Enrollment friction and a broken party flow cost more than almost anything else you could fix.