Expansion Readiness
Part of Expansion readiness
Identifying a genuine need for additional product capability
Work from the customer's task and observed gap to decide whether added product capability would solve the problem.
A genuine need begins with a customer task and a gap in the current arrangement. Identify the task, the consequence of that gap and the people affected before discussing an add-on or higher tier. Interest in a feature is a reason to investigate, not yet a reason to recommend a purchase.
Get beyond the requested feature
When someone asks for a capability, ask what they are trying to complete and what happens today. Where in the workflow do they stop, work around the system or ask another team for help? How often does that occur, and who owns the result?
Ask for a recent example the customer is comfortable sharing. Do not assume the person making the request owns the budget or final decision.
Write the need as an outcome rather than a product name. For example: “The regional team needs to complete its approval process within the same workflow.” The people doing the work can check that statement. “They need the premium package” skips the diagnosis.
Test the possible explanations
Consider four possibilities before proposing more capability:
- Existing capability is available but unknown.Show the relevant workflow and ask whether it meets the need in practice.
- Setup or process blocks use.Identify who can change the configuration or process.
- A product or entitlement limit exists.Check the customer's current arrangement and confirm that the proposed addition would remove the limit.
- The product is a poor fit for the task.Say so if an addition would leave the underlying problem unsolved.
A seat limit may justify more seats if additional people have a clear role and current users are gaining value. A team struggling with the core workflow may need an adoption or service response first.
Evaluating Possible Explanations Before Recommending Add-Ons
- Existing capability is unknown
- Show workflow; confirm if it meets the need in practice.
- Setup or process blocks use
- Identify who can adjust configuration or workflow.
- Product or entitlement limit
- Verify current limits; confirm proposed add-on removes barrier.
- Poor product fit for the task
- Acknowledge if additional capability won’t solve the core problem.
Check impact and fit with the customer
Ask what improvement would make a change worthwhile and how the customer would recognise it. That may be a completed task, fewer manual steps or access for another team. Agree the measure rather than assume a saving.
Check implementation effort too: permissions, data, training, process ownership and time from the customer's team. A relevant capability can still be poorly timed.
Imagine a customer requests an advanced reporting add-on. If the existing report uses the wrong data, fix or validate the data first. If the data is sound and a required analysis is unavailable in the current arrangement, a focused evaluation may be justified. This example describes no particular product.
Record the conclusion
Summarise the customer-stated task, affected users, observed limit, alternatives checked, proposed capability, expected outcome and remaining questions. Mark what the customer confirmed and what the team inferred. If the customer agrees to explore an option, record what they want to evaluate and who should attend. If the need remains unconfirmed, choose a discovery action and review point.
Customer Success Evaluation Metrics
- Task confirmed by customer
- Yes / No
- Affected users identified
- Number of teams or roles impacted
- Limit observed
- e.g., seat limit, data access, workflow bottleneck
- Alternatives evaluated
- Yes / No
