Case 02
Platform
Unified Buying Framework
Designing a Unified Buying Framework
Turning fragmented product offers into a contextual, needs-led buying system
Overview
Many channels. Not yet one buying system.
A large HR and payroll ecosystem offered customers many ways to discover and acquire products: a public website, a marketplace, an authenticated platform, product-specific experiences, and assisted sales and service channels.
Each channel could solve part of the buying journey. Together, however, they did not yet behave like one system. Offers were often shaped by product ownership, channel constraints, or local implementation decisions rather than by what a customer was trying to accomplish.
I was asked to explore a Buyer Framework that could create more consistency across that ecosystem. The goal was not to standardize every page. It was to define the shared logic that connects a customer need to an appropriate solution, purchase path, and next step.
How might we recognize a relevant buying need, present the right solution in the right context, and move the customer forward without making the experience feel intrusive or disconnected?
The challenge
The challenge was larger than commerce
At first glance, this could look like a storefront problem: improve product discovery, clarify the offer, and simplify checkout.
But a unified buying experience depends on decisions that happen before and after the transaction.
Ecosystem entry points
Public website · Marketplace · Authenticated platform · Product experiences · Sales & service
- What does the customer need—not merely which product are we trying to sell?
- What does the organization already know about the customer and their current services?
- Is the next step a direct purchase, a lease, a comparison, or an assisted conversation?
- Which prerequisites, dependencies, and tradeoffs must be understood before committing?
- How should context continue into fulfillment, activation, or onboarding?
- Which logic and capabilities can be reused across channels without forcing every channel into the same interface?
This reframed the initiative from a collection of upsell placements into an experience architecture problem.
My contribution
Moving the work upstream
I moved the work upstream—from individual screens to the relationships, rules, and decisions the screens needed to express.
- Mapped the fragmented buying ecosystem and its major entry points
- Reframed discovery around customer needs and business outcomes
- Created a first-pass object model for the buying experience
- Separated shared buying capabilities from channel-specific presentation
- Examined existing product initiatives as evidence for reusable patterns
- Applied the framework to two distinct authenticated-platform scenarios
- Explored contextual offers, comparison, direct purchase, lease, and assisted paths
- Facilitated conversations across Platform, Time & Attendance, Analytics, and adjacent product teams
- Documented assumptions and open questions instead of presenting hypotheses as settled decisions
01 — Reframing the system
Reframing the system around needs
The existing ecosystem could easily be described as a set of destinations: website, marketplace, product page, authenticated platform, sales, and support.
That view explains where a customer can go, but not why they would go there or how the experience should respond.
I introduced a needs-led model:
- User
- Need
- Solution
- Product or integration
- Commercial path
- Activation
Needs-led object model
Working object model
| Object | Question it answers |
|---|---|
| User | Who is acting, and what is already known about their context? |
| Need | What outcome or problem is motivating the customer? |
| Solution | What type of approach could address that need? |
| Product or integration | Which eligible offering can deliver the solution? |
| Recommendation | Why is this option relevant in this context? |
| Commercial path | Can it be bought, leased, requested, quoted, or discussed? |
| Activation | What must happen after commitment for value to begin? |
02 — Framework vs interface
Separating the framework from the interface
A shared component can make two offers look consistent while the underlying experiences remain contradictory.
- What triggers an offer?
- What evidence makes it relevant?
- What does the customer need to understand before taking action?
- Which acquisition paths are available?
- What happens when self-service is not appropriate?
- Which context should persist across channels?
I organized the framework around reusable capabilities rather than a single universal layout.
Shared capabilities
| Shared capability | Possible expressions |
|---|---|
| Recognize a need | User action, account state, usage signal, growth signal, explicit browsing |
| Match an offer | Deterministic eligibility, curated mapping, personalized recommendation |
| Explain relevance | Concise benefit, contextual reason, comparison, tier description |
| Support a decision | Prerequisites, tradeoffs, current entitlement, buy versus lease |
| Continue the journey | Direct purchase, request information, contact an expert, dismiss |
| Preserve continuity | Cart, confirmation, provisioning, activation, onboarding |
03 — Applied scenarios
Testing the framework with real buying moments
Two applied scenarios pressure-tested the framework inside the authenticated product—one relatively concrete purchase, one tiered capability upgrade.
Applied case
Scenario A: An additional employee time clock
Mapped the full commercial path for an add-on clock (catalog through checkout) and placed the offer where administrators already review connected devices—not a generic dashboard promo. Included respectful dismissals when another clock is not needed.
Framework lesson: Relevance can come from the customer's current task, even when the system does not have enough evidence to claim a specific underlying need.
Applied case
Scenario B: Analytics and reporting capabilities
Modeled a tiered analytics upgrade: what the customer has today, what each tier adds, how benefits group, what stays locked, and how to compare options without leaving the task they were already doing—education and progressive disclosure, not a single CTA.
Framework lesson: As offer complexity increases, the buying pattern must shift from promotion toward education, comparison, and progressive disclosure.
Applied scenario explorations
| Dimension | Scenario A | Scenario B |
|---|---|---|
| Offer shape | One add-on product | Multiple tiers & bundles |
| Buying motion | Purchase journey | Learn → compare → upgrade |
| Placement | Inside existing admin task | Anchored to current report task |
| Primary pattern | Contextual banner | Preview + tier comparison |
Scenario A · Time clock
Concrete add-on
- Admin reviews connected clocks (in workflow)
- Contextual offer — additional device
- Catalog & product details
- Buy or lease decision
- Cart & checkout
- Confirmation
Respectful dismiss — not needed now
Scenario B · Analytics tiers
Tiered capability
- Customer in reports / analytics task
- Current tier & what is included
- Locked capability preview
- Tier comparison (grouped benefits)
- Evaluate upgrade in task context
- Progressive upgrade path
No single promo CTA — disclose over time
04 — Pattern system
A spectrum of contextual buying patterns
The two scenarios revealed that the organization did not need one upsell component. It needed a small system of patterns matched to the customer's context and the complexity of the decision.
Contextual buying patterns
| Pattern | Best used when | Example role |
|---|---|---|
| 01Contextual banner | The offer is closely related to the current task | Offer an additional clock while reviewing connected clocks |
| 02Recommended card | A credible account or usage signal supports the recommendation | Surface a relevant capability from a dashboard |
| 03Locked capability preview | The customer encounters value beyond the current entitlement | Explain what an advanced analytic could provide |
| 04Tier comparison | The customer must evaluate multiple capability bundles | Compare Analytics and Reports levels |
| 05Product detail flow | The decision requires specifications, prerequisites, or commercial options | Explain a clock and buy-versus-lease paths |
| 06Assisted path | Eligibility, configuration, or pricing cannot responsibly be self-served | Connect the customer with the appropriate expert |
05 — Trust
Designing trust into recommendation moments
Authenticated products create a delicate boundary. The organization may know more about a customer, but that does not make every promotional message feel helpful.
I used four principles to evaluate contextual offers:
01
Earn the placement
The offer should relate to the task, account state, or explicit signal available in that moment. When the evidence is limited, the copy should not pretend to know more than the system does.
02
Explain the relevance
The experience should communicate the customer benefit before the commercial action. More complex offers require more explanation, comparison, and visibility into prerequisites.
03
Match the commitment
A low-complexity, eligible product may support direct purchase. A configurable service or tier change may require education or assistance. The CTA should reflect the real operational path.
04
Preserve control
Customers should be able to dismiss an offer without completing an unnecessary questionnaire or repeatedly encountering the same recommendation.
These principles transformed "upsell" from a placement problem into a trust and decision-quality problem.
06 — Collaboration
Working across organizational boundaries
The framework crossed product and team ownership. I used active initiatives as pattern evidence and brought together perspectives from Platform, Time & Attendance, Analytics, and other teams already solving related commercial problems.
The goal of those conversations was not simply to review finished screens. It was to understand:
- Which capabilities or patterns already existed
- Whether proposed work conflicted with planned initiatives
- Which decisions belonged to Platform versus individual products
- Where reuse was desirable and where product context required variation
- Which assumptions still needed business, data, legal, or operational validation
This collaboration helped prevent the framework from becoming an idealized journey disconnected from delivery reality.
07 — AI workflow
Using AI as a thinking partner—with human approval
I also tested an AI-augmented design workflow for parts of the discovery and modeling process:
- Generate
- Review
- Refine
- Visualize
- Human approval
Useful for
- Accelerating divergent thinking
- Reorganizing information
- Producing early structural options for product discovery, object modeling, and opportunity mapping
Less reliable when depending on
- Unspoken business rules
- Authoritative product information
- Stakeholder intent
- The distinction between evidence and a plausible-sounding assumption
The experiment reinforced an important boundary: AI could accelerate synthesis and exploration, but it could not own the recommendation logic or validate the operating model.
Outcome
A strategic foundation—not a finished storefront
This work established a strategic foundation for treating buying as a connected product capability rather than a series of isolated promotions.
- A needs-led framing for the buying ecosystem
- A first-pass object model and relationship map
- A shared-capabilities view across public, authenticated, self-service, and assisted channels
- A spectrum of contextual buying patterns
- Applied explorations across a straightforward product purchase and a more complex tiered capability decision
- Clearer criteria for relevance, explanation, commitment, and customer control
- A visible register of the decisions, ownership questions, and validation still required
Evidence board
Facts
- Buying journeys span public, authenticated, product, sales, and support entry points
- Offers were often shaped by ownership and channel constraints rather than customer needs
- Two applied scenarios pressure-tested the framework: device purchase and tiered analytics
Hypotheses
- A needs-led object model can create decision consistency across channels
- Contextual placement outperforms generic dashboard promotions when task context is strong
- Offer complexity should change the buying pattern, not just the copy
Open decisions
- Authoritative eligibility and recommendation rules
- Taxonomy ownership and governance
- Target-state journeys and success measures beyond conversion
The framework remained hypothesis-led at this stage. Recommendation rules, taxonomy ownership, target-state journeys, governance, and success measures still required organizational agreement and validation. Making those gaps explicit was itself a meaningful outcome: it prevented polished concepts from implying capabilities or certainty the organization did not yet possess.
What I learned
What the work made visible
A unified experience is shared logic, not identical UI
Channels can look different and still belong to one coherent system. Consistency comes from shared definitions, eligibility rules, decision support, and continuity—not from repeating the same component everywhere.
Context is valuable only when the experience uses it honestly
The system should distinguish between what it knows, what it infers, and what it is merely offering. Overstating personalization can weaken trust faster than a generic message.
The offer must scale with the decision
A simple additional device and a tiered analytics capability should not use the same buying pattern. The amount of education, comparison, and assistance should reflect the customer's risk and commitment.
Strategy becomes credible when it survives a concrete case
The framework became more useful when applied to real product constraints. The examples exposed where a principle was reusable and where the experience needed legitimate variation.
What I would do next
Where the framework still needs validation
- Validate the actor, need, and solution taxonomy with customers and internal teams
- Define the authoritative eligibility and recommendation rules for one priority scenario
- Map the end-to-end current state, including operational ownership and system handoffs
- Test whether customers understand why an offer appears and whether it feels useful rather than intrusive
- Establish metrics beyond conversion, including decision confidence, dismissal behavior, support escalation, activation completion, and repeat exposure
- Define governance for taxonomy, recommendation logic, content, and reusable patterns
Reflection
Screens follow shared buying logic
The most useful contribution was not a universal upsell component. It was a way for the organization to reason about buying as shared logic—needs, relevance, commitment, and continuity—before deciding how any single channel should look.
“A unified experience is shared logic, not identical UI.”