Five dimensions that matter in B2B SaaS post-sales growth

B2B SaaS companies separate Sales from Delivery, especially where there is something to build/configure/migrate before the customer can see full value. That separation is a symptom of an upstream change started by Aaron Ross with his work at Salesforce in the early 2000s creating the first Sales Development Rep (SDR) roles. The SDR and the Account Exec. (AE) split was later codified in the book Predictable Revenue (2011) and has been copied ever since at SaaS companies. This change resulted in huge benefits to sales, but does nothing for post-sales. Is that boundary still the right one? The AE as "closer" creates the end to sales, the start of delivery, and transforms a prospect into a customer. It's the stop/start transition that creates the first customer weak point and one of the five key dimensions affecting post-sales success.

Handover is one of the key five dimensions, the others are: Implementation, the CS Operating Model (CS), Knowledge Concentration and Enterprise Readiness. The first three you're already aware of, managing, but not always focused on from the customer's experience side. The last two bring their own risks: one breaks individual dimensions, the other breaks everything if you're not prepared. Even for non-enterprise projects, cumulative multi-dimension gaps change the customer experience in ways that are harder to recover from. Each of the five dimensions has two sides when things don't go right, the pain we're directly aware of as the vendor and pain for the customer. We log this side as the customer being worried, upset, amber/red, low CSAT without directly acknowledging the specific pain caused.

"Handover" sounds straight forward enough but it comes with the first set of real risks if we haven't prepared for it. As the vendor, ring the bell, sale done, pass some information to the delivery teams. As the customer, "now we can start having our hopes, dreams and promises realised." If the AE gets pulled back in to de-escalate scoping issues, the customer is already asking, "did we make the right choice? We're starting again with explanations to a new team and they're not aware of key elements during the sale." They're still holding the promises with hope, but some of the dreams already died. During Implementation, delays cause us capacity problems and eat into margin, for the customer - the internal champion is wondering why, has to defend the delay, and the decision to choose you in the first place. They start thinking about their job rather than the project. If we're not proactive in the CS Operating Model, renewals are a surprise, NRR is reported rather than actively managed. And the customer: "no one noticed us unless something broke or we're spending more money." The CS function is about expansion, but a relationship-led expansion is very different from an expansion-led relationship.

Startups need good people, and good people do great things, learning and soaking up extraordinary and specific knowledge along the way. Don't keep it just in their heads, even if a brain consuming ~20W is more power-efficient than a knowledgebase server. Quick Test: Someone asks you a technical question about your product. Do you tell them who to ask or where to find the information? If it's the first one, you might have a Knowledge Concentration problem. This can affect the handover, implementation or CS if the key person leaves. Guess what, most customers have a knowledge concentration problem, and they're relying on your team for much of it. If you don't "back-up" that knowledge and "their person" leaves, you look very careless and trust breaks down.

That compounds even further when dealing with enterprise customers. Enterprise Readiness will show up during sales first, and if you're not ready for a different type of customer when you land them, every function post-sales will break one by one like the support cables of a bridge in a bad disaster movie. The handover involves more stakeholders, more detailed project plans, stage gates, sign-offs and checks against SLAs that you might not have had before. Every change to design will be scrutinised against the scope; any ambiguity in the SoW feeds uncontrollable expansion of the project. Shadowy figures known as procurement are the gatekeepers of change orders, not the nice team you deal with on a daily basis. In an enterprise project, the key stakeholders have had to go through an unimaginably difficult process just to sign your contract; they might also be staking their career on its success or failure. I've illustrated that Enterprise Readiness is fundamental to everything else and if you haven't built it as a foundation, it puts everything else at risk. It's also the one thing that's a leading indicator - it shows up in sales. You have a choice to qualify them out if they're too big, or get systems and your people (or extra hired guns) in place for next level delivery.

You can't scale your way up just by looking at the linear processes of handover, implementation or CS in isolation; you get that in your CS 101 training. Knowledge Concentration amplifies the problems, forcing you beyond "can we do it", to "how do we do it repeatedly and consistently." Adding in Enterprise Readiness as a foundation gate gives us "when to say no, and when we say yes - that we know we can do it repeatedly, consistently and to a recognised standard."

I've outlined the building blocks of what's needed to scale B2B SaaS post-sales beyond early-stage growth. Getting these dimensions right allows you to land, deliver and grow customers at volumes and complexities that move you beyond your current limits. It also lets you have a bit of swagger into your next board meeting, because you know where the answers are, not just who in the team to ask. This is the start of a series where I'll dive deeper into each dimension, and outline more specific challenges and fixes you can put in place to master each one.

If this hits a note, book a free call to talk about it.