Start with the expansion job
An expansion opportunity is a customer-relevant change in scope that could help the account perform an existing or adjacent job. The opportunity type determines the evidence you need:
| Type | Possible evidence | Question to validate |
|---|---|---|
| Seat or user | Eligible people lack access while the workflow is established | Which roles need to participate, and why? |
| Team or department | A second group repeats a similar workflow or requests access | Does the same job exist in that team? |
| Workspace or project | Repeated setup or separation work across units | Would another workspace improve governance or delivery? |
| Product area or plan | An established workflow reaches a relevant adjacent capability | What customer outcome would the capability support? |
| Capacity | A fair, documented limit constrains a valuable workflow | Is the limit the real constraint rather than poor configuration? |
| Governance or security | Scale creates permission, audit, or administration requirements | Which verified control is missing? |
| Automation or integration | Repeated manual handoffs, exports, or setup work | Where does the data go and what makes the handoff costly? |
One signal, four honest readings
Product signal
42 manual exports
after completed reports, 30 days, Atlas Labs · core reporting adoption stable · 7 analysts, 1 admin
This is one observation. It is not yet an opportunity.
Automation or integration
ifthe file feeds a downstream system on a fixed schedule
askWhere does the data go, how often, and what makes the handoff costly?
Seat or team
ifpeople outside the account re-key the same output by hand
askWho receives it today, and which roles need to participate directly?
Product area or plan
ifscheduled delivery already exists and the account cannot reach it
askWould scheduling remove the handoff, or just move it?
No opportunity
ifthe export is the required format for a legacy process the customer keeps
thenClose the hypothesis and record why. The behavior was never a need.
Four readings, one set of evidence. The distinguishing facts — destination, recipients, eligibility, intent — are not in the product data at all, which is why the next step is a question and not an offer.
Keep product evidence and commercial qualification separate
- Product signal: a measured behavior, change, gap, request, or constraint.
- Product opportunity: a plausible next workflow supported by context.
- Customer need: the customer confirms the problem or desired outcome.
- Commercial qualification: stakeholder, budget path, authority, timing, contract, and willingness are understood.
- Expansion: the customer chooses a larger scope.
Do not collapse those stages into a “purchase likelihood” score. Stable core adoption is often a starting condition because it shows an existing workflow may create value. Yet strong use can also be focused success with no adjacent need, and a sudden volume spike can be temporary, automated, or caused by friction.
Where product evidence stops
Product signal
A measured behavior, change, gap, request, or documented constraint
Product opportunity
A plausible adjacent workflow, supported by role, eligibility, and lifecycle context
Customer need
The customer confirms the problem or the outcome they want — in their words, recorded separately
Commercial qualification
Stakeholder, authority, budget path, timing, contract, and willingness are understood
Expansion
The customer chooses a larger scope
83% likely to expand
A single number spanning all five stages claims knowledge of budget, authority, and timing that no product event contains. Keep the stages separate and the hypothesis stays reviewable: which evidence, which stage, whose statement, what is still unknown.
Timing changes the next action. A new account still configuring core workflows usually needs onboarding. A mature account with recurring value and a repeated adjacent handoff may be ready for discovery. A renewal under procurement pressure may have a genuine product need but the wrong commercial timing. Preserve lifecycle and customer context instead of letting the latest event decide.
Read signals with user, role, and account context
Look for adjacent workflow evidence rather than volume alone: repeated manual exports after a stable reporting workflow, several eligible users requesting access, a second department following a proven sequence, or recurring administration pressure caused by genuine scale.
Distribution can support either an opportunity or a risk diagnosis. Calculate and display the underlying evidence:
Eligible-user penetration
Eligible-user penetration = eligible users performing the meaningful workflow ÷ all eligible active users × 100
Top-user concentration
Top-user concentration = qualifying activity from the top user ÷ total qualifying account activity × 100
Low penetration can indicate available seat or team scope, but it can also be correct for an administrator or specialist workflow. High concentration can indicate proven ownership or fragile dependence. Review role expectations, permission coverage, backup ownership, lifecycle, and the customer's own operating model.
Peer gaps are contextual, not proof. Build comparison groups from relevant plan, lifecycle, size, industry, workflow, and eligibility dimensions; show the group and distribution. Never convert “similar accounts use more” into an automatic sales message.
Validate capacity separately
Capacity signals require special care. Record the customer's actual allocation, sustained use, failures or queued work, notification history, and whether the limit is contractually clear. Separate true demand from accidental overcollection, inefficient configuration, abusive design, or a one-time spike. A fair limit can support a conversation; artificial scarcity cannot.
Use a transparent investigation framework
Preserve dimensions as present, partial, unknown, not applicable, or blocking so reviewers can see why a hypothesis exists.
| Dimension | Question | Evidence | Common blocker |
|---|---|---|---|
| Customer job | What outcome is the account pursuing? | Use case, workflow, role, stated objective | No underlying job |
| Current need | What repeated behavior or constraint exists now? | Frequency, trend, workaround, requests, Visits | One ambiguous event |
| Core adoption | Is the related workflow established? | Meaningful completion, recurrence, outputs | Core value not reached |
| Role readiness | Are the right people present? | Eligible roles, permissions, penetration, concentration | Missing owner or backup |
| Adjacency | Does the capability continue the current job? | Sequences, handoffs, shared data, repeated setup | Merely unused |
| Friction | Is a product or support issue more urgent? | Errors, abandonment, support context | Open blocker |
| Commercial context | Are authority, priority, budget path, and timing known? | Customer statements and account records | Unknown willingness |
| Confidence | What is known and what must be learned? | Source links, alternatives, owner, next question | No human review |
Useful triage states are: support first, strengthen adoption, investigate, validate with the customer, commercially qualify, and no current hypothesis.
Store the source period and links behind every dimension. A reviewer should be able to open the Company, see which grouped Pages and Users contributed, inspect the exact limit or repeated action, and understand which alternative explanations remain. Confidence should fall when identity, eligibility, instrumentation, or customer-job evidence is weak.
Route the next action
Use the triage state to control workflow. Support first creates a product or service owner and suppresses expansion outreach. Strengthen adoption focuses on role coverage or backup ownership. Investigate assigns a question and evidence owner. Validate with the customer prepares discovery. Only a customer-confirmed need should move to commercially qualify.
If a ranking is needed for operational queues, keep it decomposable. A reviewer should see that an account ranked highly because core adoption is recurring, a manual handoff occurred 42 times, several eligible roles participate, no current blocker is visible, and commercial context is unknown. Do not expose a false precision such as “83% likely to expand.”
Worked examples: similar activity, different actions
The accounts and patterns are fictional. They illustrate why one score cannot replace judgment.
| Account | Observed pattern | Interpretation limit | Next step |
|---|---|---|---|
| Atlas Labs | Stable core adoption and repeated manual reporting handoffs | Customer intent is unknown | Ask about the downstream job |
| Northstar Works | High activity concentrated in one user | May be intentional specialization | Confirm ownership and backup before expansion |
| Beacon Systems | Workflow appears in a second department | Need and authority are unconfirmed | Validate team relevance |
| Meridian Group | Repeated errors and incomplete setup | Volume reflects friction | Support first |
| Harbor Analytics | Narrow, stable use of one area | Focused use may be healthy | No current hypothesis |
| Summit Operations | Repeated workspace setup and permission work | Could be configuration or governance need | Investigate operating model |
Six accounts at the same activity level, six different next steps
Roughly a third of runs end in an error. The volume is friction, not demand — expansion outreach is suppressed until it is fixed.
Top-user concentration 89%. Specialist ownership may be intentional; confirm a trained backup before treating the account as ready for more scope.
Recurring value plus 42 manual exports. Ready for discovery, not a pitch: ask where the data goes before naming any capability.
Could be a governance requirement or simply poor configuration. A larger plan is not the answer until that is settled.
Focused use of one area, working as intended. An unused product area is not evidence of a need.
The same sequence in a second department is a lead for a question, not proof the department has the same job or the authority to buy.
Nothing here is ranked by volume. The busiest account is the one to leave alone, and no account reaches commercially qualify — not one of them has said yet that the problem is worth solving.
Atlas is ready for discovery, not a pitch: ask about the repeated handoff. Northstar needs continuity validation. Beacon needs confirmation that the second department has the same job. Meridian needs support. Harbor may require no action. Summit needs an operating-model conversation before anyone assumes a larger plan is the answer.
The same account can move between states as evidence changes. If Atlas confirms that exports feed a required legacy process and no automation is desired, close the hypothesis. If Northstar confirms intentional specialist ownership and a trained backup, concentration is no longer blocking. If Meridian's errors are fixed and the adjacent workflow later recurs, reevaluate from fresh evidence rather than preserving an old score.
Improve the customer conversation responsibly
Turn a signal into questions about the workflow: who performs it, what output it supports, where work leaves the product, what makes the current process hard, whether another team has the same job, and what outcome would make a change worthwhile. Record customer confirmation separately from the original behavioral signal.
A good discovery note contains the observed period, affected users and roles, customer job, current value evidence, possible adjacent capability, blockers, alternatives, confidence, customer statement, commercial owner, and next step. If the customer says the current process is intentional and satisfactory, close or downgrade the hypothesis.
Use evidence responsibly
Use purpose-limited data, avoid sensitive inference, restrict detailed user and replay access, and explain why a hypothesis surfaced. Do not use dark patterns, artificial scarcity, opaque scores, or covert monitoring. Capacity prompts should reflect fair, documented limits—not engineered pressure. If automated ranking helps order review work, keep it versioned, decomposable, and subject to human review.
Detailed individual activity should be available only to people with a legitimate product or customer-success purpose. Prefer account-level summaries for routine review; open user or replay evidence only when it answers a named question. Do not infer sensitive traits, employee performance, or private intent from product behavior.
Ask about the workflow
Discovery questions should stay close to the customer's work: What happens after this export? Which team needs the output? How often does the handoff occur? Who owns it today? What breaks at current scale? Is another workspace required for governance or simply convenient? What outcome would make a change worthwhile? These questions invite correction instead of presuming a purchase.
When the customer confirms a need, document that statement independently from the original signal. Only then should the commercial process establish stakeholders, authority, budget path, timing, contract constraints, and willingness. A product-qualified hypothesis and a commercially qualified opportunity are different records.
- Start in the Company and confirm identity, plan, lifecycle, and current objectives.
- Verify recurring core value before looking for adjacency.
- Inspect relevant product areas, grouped pages, and repeated workflows.
- Review eligible Users, roles, penetration, and concentration.
- Open selected Visits only to resolve a named uncertainty.
- Write the signal, alternatives, blockers, confidence, and next question.
- Validate the job with the customer.
- Qualify authority, budget path, timing, and willingness in the commercial process.
- Close the hypothesis when evidence or the customer says it is not relevant.
Re-evaluate open hypotheses after product fixes, team changes, plan changes, or a completed customer conversation. Expire stale evidence rather than allowing an old usage spike to stay in a queue indefinitely. Record why a hypothesis was closed: not relevant, support resolved, timing deferred, insufficient evidence, customer declined, or commercially disqualified.
Avoid designing in-product prompts that exploit behavioral monitoring. A limit notice should explain the current allowance and options clearly; it should not imply that private user activity has been individually watched. Give customers predictable controls and a way to make an informed choice.
How Hymetry supports expansion investigation
Hymetry connects Companies with adopted product areas, grouped Pages, contributing Users, and selected Visits. Teams can inspect whether a signal reflects a broad workflow, one champion, an adjacent pattern, or visible friction before deciding what to ask.
Hymetry supplies product evidence; the customer supplies need and outcome; customer-facing teams and commercial systems supply authority, timing, contract, and willingness.
Frequently asked questions
How should teams approach expansion from usage data?
Start with established value and an adjacent job, preserve alternative explanations, validate the need with the customer, and qualify commercial context separately.
Can product usage predict an upsell?
It can prioritize hypotheses but cannot establish budget, authority, timing, intent, or a purchase decision.
What are strong SaaS expansion signals?
Repeated adjacent workflows, eligible-role requests, fair capacity constraints, multi-team spread, manual handoffs, and governance needs are useful when core adoption and customer relevance are established.
Is an unused product area a cross-sell opportunity?
Not by itself. The account may be ineligible, unaware, blocked, too early, or simply have no relevant job.
How do you identify seat expansion?
Show that additional eligible roles need to participate in an established workflow and that missing access—not weak adoption or permissions—is the constraint.
When should customer success contact the account?
When evidence supports a relevant question and urgent blockers have been resolved. The conversation should validate the job, not announce a predicted sale.
Should opportunities be scored?
A score may rank review work, but keep dimensions visible, version the rule, document uncertainty, and never present it as universal purchase likelihood.
Sources
Vendor sources document common analytics and customer-success practices; they are not independent proof that a usage pattern predicts willingness to buy or expansion revenue.
Analytics, product-led sales, and customer success
User needs, ethics, and privacy
- GOV.UK: Understand users and their needs
- Nielsen Norman Group: Contextual inquiry
- Christensen Institute: Jobs to Be Done
- UK ICO: Data minimisation
- US FTC: Bringing Dark Patterns to Light
- NIST AI Risk Management Framework
