Business to Business to Consumer

For a long time the question of who you sell to had two answers. Either you sell to companies, which is business to business (B2B), or you sell to individual consumers, which is business to consumer (B2C). Some companies stopped making sense the moment you tried to file them under one of the two. The signature on the contract belongs to a business, but the person opening the screen every day isn't an employee of that business — it's one of its customers.

A company that drops a checkout widget into an online store works exactly this way. The contract is with the store and the store pays the invoice. The person looking at the checkout screen is whoever is buying a pair of shoes, and that same shopper is the one who gets annoyed when the form asks for a card number three times. Inside a company like that, the word "customer" pointed at a different person depending on who said it. Sales pictured the store, support pictured the shopper, and the same word carried two conversations.

Business to business to consumer (B2B2C) is the label that filled the gap. Writing one more B into the middle is enough to show that the path money takes and the path usage takes have come apart.

Three positions sit in a line: the company that builds the product, the company that puts that product inside its own service, and the individual who uses that service. The company in the middle is usually called the partner.

Each position does something different.

1. You build the product and sign with the partner. This is where revenue arrives. Sometimes it's a flat monthly fee, sometimes it's a share of what the partner earns from its own end users. Under the second arrangement your revenue only grows when the partner's business grows.
2. The partner embeds your product in its service and puts it in front of its own customers, usually under its own brand. Stripping your name off and shipping the product under the partner's logo is called white labeling.
3. End users use your product without ever signing anything with you. Plenty of them never learn your company's name, and when something breaks they contact the partner's support desk, not yours.

The split between those two paths is the whole structure. Money comes from the partner, usage happens with the end user, and requirements collide head-on as a result. The partner wants its brand large and prominent; the end user wants one fewer step before paying. The partner asks for more fields in the signup form, and every field added pushes more end users to abandon it halfway.

Where responsibility ends also gets written into the contract in advance. When the screen freezes for thirty minutes, the partner is the one writing the apology and you are the only one who can fix the cause. Unless the contract says how fast you have to report an outage, and how far the partner handles end-user questions before passing them to you, the day something breaks gets spent looking for each other.

It comes up most often when deciding what to build first. One partner signing on can bring tens of thousands of users through the door at once, so the preparation looks different.

Three things move up the build order. Per-partner settings that swap out colors and logos, a multi-tenancy architecture that lets many partners share one system while making each partner's data invisible to the others, and a software development kit (SDK) that the partner's engineers use to drop your features into their service. A product sold directly to individuals wouldn't build any of these for years.

Numbers have to be counted on two levels. Counting partners alone tells you nothing about whether the product is actually used; counting end users alone hides which partner is carrying the revenue. So you pair the end users one partner brought in with the revenue that partner generates. Unit economics, the question of what's left over per unit of customer, gets calculated per partner too.

Sales and marketing split the same way. Landing one partner takes months of meetings, and you can't run ads at the end users underneath because you don't hold their contact details. Growth happens along exactly two paths: add partners, or get the users of existing partners to use more.

"This is B2B2C — if we add the fields the partner asked for, end-user signup conversion drops."

An objection that the partner's request will cost users further down the chain.

"Can we break that metric out by partner? Aggregated like this I can't see where the problem is."

The overall average is hiding one partner's decline.

"End-user data belongs to the partner, so we can't email them directly."

Blocking a marketing proposal on contract terms.

Pagedeck met this structure for the first time through a contract with an education platform. The platform put the Pagedeck document editor into the screen where students submit assignments, and both the contract and the payments ran through the platform alone. The people opening the editor were 40,000 students.

From then on Mia kept requirements in two separate lists. Mixed into one table, the items from the platform's contact always got handled first. What Sofia brought back from the platform was logo placement and an admin dashboard; what came up from students was a three-second wait after pressing save. Grace argued for serving the side holding the contract, and Mia argued that students who stop using the editor mean no renewal next year.

The most common misreading is that B2B and B2C have been combined, so you get the advantages of both. The picture of stable enterprise contracts plus consumer-scale reach forms easily. In practice you get two gates instead of one. First the months-long sale that convinces the partner, then the separate job of getting the users underneath to actually use the thing. Clearing one gate without the other gets you nothing. A signed contract with no usage doesn't renew, and users who love the product vanish all at once if the partner decides to remove you.

Treating end users as your customers is the other frequent mistake. They're using your product, so they look like your users, but contractually their data usually belongs to the partner. Sending them a promotion or a survey needs the partner's permission, and that permission gets refused. Count those users as your own asset and the day one partner leaves, the tens of thousands underneath it walk out together and the plan falls apart at once.