PLG + SLG hybrid: When self-serve meets enterprise sales

The first time I realised we had a problem, I was sitting in on a call with enterprise procurement at Freshworks. The buyer, a mid-level IT manager at a logistics company, had pulled up our pricing page and was reading it out loud to us. Slowly. With the energy of someone trying to assemble furniture using instructions translated through four languages. "So this tier includes five agents, but your sales rep quoted us fifty seats with a different per-agent price, and the website says I can start free with up to ten. Which one is the real price?"

I did not have a good answer. Neither did anyone else on the call.

That moment was a small, specific symptom of a much larger problem. The product had been built for self-serve. Small teams could sign up, try it, pay with a credit card, and start using it within an hour. It worked beautifully for that motion. But as the company grew and started pursuing larger accounts, a sales team appeared. And the sales team had different pricing, different packaging, different terms. The self-serve product and the enterprise sales process were not designed to coexist. They had been stitched together after the fact, and the seams showed.

Act One: the food truck that wanted to be a restaurant

Every product-led growth story starts the same way. You build something useful. People find it. They sign up, use it, pay for it. No salespeople required. The product does the selling. It is elegant, efficient, and deeply satisfying for anyone who has spent time in the slow, expensive machinery of traditional enterprise sales.

But then something happens. A larger company shows interest. They want the product, but they also want a contract, an SLA, custom onboarding, invoicing through their procurement system, a dedicated account manager, and a security review that takes three months. They do not want to put a credit card in and start a free trial. They want to buy the way large companies buy.

PLG and SLG are two different organisms sharing one body. One breathes through speed, simplicity, and low friction. The other breathes through relationships, negotiation, and long cycles. The instinct is to run both. The reality is that running both is like a food truck owner who gets popular and decides to open a fine dining restaurant using the same kitchen, the same menu, and the same staff. The ingredients might overlap. But the operation is fundamentally different, and pretending otherwise produces a terrible version of both.

Act Two: the motion collision

This is where the chaos lives.

At Freshworks, I watched this collision happen in real time. The self-serve pricing was designed to make small teams say yes quickly. Low entry price, transparent tiers, instant access. But when the sales team quoted enterprise deals, they used different bundles, volume discounts, and annual contracts that looked nothing like what was on the website. Enterprise buyers who had started as self-serve users found themselves in a confusing middle ground: they could see one price online and were being quoted a completely different structure by a human.

The pricing page that made sense for startups confused enterprise procurement. Procurement teams are trained to find inconsistencies. When they see a public price that differs from a quoted price, they do not think "oh, that is the self-serve tier." They think they are being overcharged. Or they think the sales rep is undercutting the standard price, and they push for more.

But the pricing was not even the hardest part. The product itself had been built for the self-serve motion. Onboarding was automated. Billing was monthly, by credit card. There was no concept of a multi-year contract, a purchase order, or an invoice that needed to go through three levels of approval. Bolting enterprise billing onto a self-serve billing system is like attaching a trailer to a bicycle. It technically connects. It does not work.

I have been mentoring a founder who learned this the painful way. She had built a solid self-serve analytics tool. Hundreds of small teams paying monthly. Good retention. Then a Fortune 500 company wanted to buy it for three hundred users. Great news, in theory. But the billing system could not generate an invoice. It could not handle annual contracts. It could not accommodate the client's requirement for net-60 payment terms. The founder spent two months building billing infrastructure instead of product. She told me, with the weary honesty of someone who has been in the weeds too long, that she had accidentally built two companies and neither one was working properly.

That is what I call the billing Frankenstein. You start with a clean, simple billing system designed for one motion. Then you bolt on pieces for the other motion. Custom invoicing here. Contract management there. A manual process for enterprise renewals that someone runs out of a spreadsheet. Before long, you have a system that no single person fully understands, held together by duct tape and good intentions.

Act Three: the uncomfortable coexistence

Here is the thing nobody wants to hear. There is no clean solution.

The companies that make the hybrid work do not eliminate the tension. They accept it and build walls around it. They run two motions with two distinct operational tracks. Self-serve has its own pricing, its own onboarding, its own billing, its own success metrics. Enterprise has its own. The product is shared. Almost everything else is separate.

But that is expensive. It means two sets of processes. Two billing systems, or at least two configurations of one. Two onboarding experiences. Sometimes two support teams. For a startup trying to move upmarket, the cost of running both motions properly can feel disproportionate to the revenue the enterprise motion generates in its first year.

The alternative is worse. Trying to force both motions through one system produces the confusion I saw at Freshworks, the billing problems the founder I mentored hit, and a customer experience that satisfies nobody. Enterprise buyers feel like they are using a consumer product with a contract stapled to it. Self-serve users feel like the product is getting heavier, slower, more complicated, because it is. Every enterprise feature request adds weight to a product that was built to be light.

The teams I have seen handle this best share a specific discipline. They decide, explicitly, which motion is primary. Not both. One is the core. The other is the extension. If PLG is primary, the enterprise motion is a layer on top, with its own pricing and process, but the product stays optimised for self-serve simplicity. If SLG is primary, the self-serve motion becomes a trial mechanism for enterprise pipeline, not an independent revenue line.

The moment you treat both as equally important, you get the worst version of each.

What stays quiet

Most product teams I talk to about this are already in the middle of it. They have a self-serve product generating revenue. They have an enterprise pipeline generating interest. And they have a growing sense that the two things are pulling the organisation in opposite directions.

The hardest part is not the billing system. It is not even the pricing. It is the identity question underneath: what kind of company are you? A product-led company that also sells to enterprises? Or an enterprise company that also has a self-serve option? Those are different businesses with different centres of gravity. The ones that stall are almost always the ones that refuse to choose.

Every hybrid model is a negotiation between two versions of the same company. The negotiation never ends. But it goes better when someone names the terms.