Launch Readiness With a Support Team That Never Saw the Product
A B2B SaaS company is launching a major platform update in five weeks. Marketing has built a campaign around three new features. Engineering confirms two features are complete; the third is at 70% and may slip. Customer support has received no training and has not seen the new interface. The top 20 accounts have been promised a smooth transition by the sales team. The launch date was set eight months ago to coincide with an industry conference, and the CEO is unwilling to move it. A pre-launch review found that the support team's knowledge base still describes the old interface.
1. Assess launch readiness across the dimensions that matter and identify the highest-risk gap.
Read the worked answer
Readiness dimensions: product completeness, support readiness, customer communication, and commitment integrity.
- Product: one of three features at 70% with slip risk. The campaign's central promise is partially at risk.
- Support: no training, no interface exposure, stale knowledge base. This is the highest-risk gap. When the update ships, support is the first line of contact for confused customers, and they will be both uninformed and unable to diagnose issues. The damage compounds: support failures during launch are highly visible and erode trust with exactly the top accounts that were promised a smooth transition.
- Communication: campaign built on a feature that may not ship.
- Commitments: top-20 promises create expectations the organization may not meet.
The highest-risk gap is support readiness, because it is the least recoverable in five weeks and the most visible at the moment of launch.
2. The CEO refuses to move the date. Recommend a launch approach that manages the risk without a blanket delay.
Read the worked answer
Decouple the launch from a single all-or-nothing event.
Scope the launch. Ship the two complete features and the third only if it clears a go/no-go gate at T-10 days. Adjust the campaign to feature what will actually ship; do not promise the slipping feature.
Stage the rollout. Release to a small cohort first (internal, then a friendly subset of accounts), with the top-20 handled individually. This converts a cliff into a ramp and gives support real exposure before broad release.
Fix support before anything ships. Five weeks is enough for interface walkthroughs, a knowledge-base rewrite, and a scripted escalation path. Make support sign-off a launch gate.
Manage the top-20 commitments directly. Have account owners brief them on the staged rollout and the support plan; a proactive call is far better than a surprise.
The conference date can be honored for the two ready features without betting the launch on a 70%-complete feature and an untrained support team.