Loading
Loading
case
case
study
study
2025
2 weeks
Product design
A service is the core unit used to sell products on the platform. It includes the product itself (program, sessions) and pricing (cost and payment model), which is configured directly inside the service and is its inseparable part.
Initial problem — Sales customization created operational overhead
To sell the same service with different prices teams were forced to duplicate services.
×5–10 copies per service — huge effort in managing and errors when updating all service copies.
More time tracking client progress across service copies.
Goal — Enable flexible pricing without service duplication
Keep “one product — one service” principle
Reduce admin effort in managing services
Simplify tracking of client progress and sales
My role
As a Product Designer, I owned the end-to-end user experience: analyzing existing workflows, designing a solution that is safe, reliable, and transparent for admins, collaborating with PM, CS, and devs to align with business and technical requirements, design review and gathering post-release usage feedback to refine the solution.
First idea was adding multiple prices inside a service
However, once we dug deeper, it became clear that simply supporting multiple prices inside a service wasn’t enough.
Understanding use cases
Working closely with Customer Success and PM, I identified all recurring sales use cases and translated them into actionable job stories. These use cases consistently surfaced both among existing customers and during demo sessions, and the lack of support for them significantly reduced the platform’s attractiveness for potential customers.
Key insight — Multiple service prices address only one use case
It's only fixes duplication.
Most scenarios remain unsupported:
Payments handled outside the platform for bundled services — admins manually enroll clients and consolidate data, increasing workload.
Errors and inefficiencies with custom offers — assembling unique combinations manually leads to mistakes, wasted time, and difficulty reusing configurations.
Risk of outdated or inconsistent offers — without centralized tracking, clients may receive incorrect sets of services or pricing when multiple people are involved in the sales process.
The initial problem (service duplication) turned out to be only a symptom of a deeper issue: the platform lacked a model for complex sales scenarios — bundling, custom proposals, paywalls, and team-based selling.
Even without direct complaints, this was already hurting both the operational efficiency of existing customers and the platform’s attractiveness in sales demos with potential ones.
Development alignment
"Adding multiple prices inside a service would be a technical dead end. If we ever need bundles or custom proposals, this solution would have to be thrown away and rebuilt from scratch."
No service duplication
Reduces manual work & errors in complex sales
Gives admin visibility & control in team-based selling
Boosts platform sales
Avoids a technical dead end
Simple fix
Scalable solution
Shaping the Solution
I studied the current flows → identified the goals and constraints of each role → analyzed competitors (how they solve similar problems and what could be useful for us).
The pricing exists in the context of a deal, not the service.
A deal is essentially a document — an email, a Notion page, or a Google doc — where an admin describes a specific agreement and manually includes a link to a service with a specific price.
The problem: External tools know nothing about the services
Service links must be manually copied, which is time-consuming and error-prone.
Admin must manually keep documents in sync with reality: if a price changes in the system or a service is removed, the deal document becomes outdated unless updated.
Solution — In-platform deal object connected to services. We called it Offer.
I was inspired by how Hellobonsai use a visual builder for their Proposals — you can immediately see what the final result will look like. It also allows using the same layout for both admin and client, reducing development effort.
Where the pricing should live?
Service level: Doesn’t support bundles, where the price must exist outside the service.
Offer level: Breaks combined offers, where each service has its own price.
Inspired by Hubspot’s Line Items, I designed Offer Item — a container for pricing and other offer-specific purchase conditions.
Offer Item brings maximum flexibility:
No service duplication — the same service can be reused across any number of offers
Enables paywalls by adding the same service multiple times with different pricing.
Supports bundles within one consistent model
Paywalls
An Offer Item allows the same service to be added multiple times with custom pricing.
A service may present to client multiple purchase options: one-time payment, subscriptions, membership, etc. For the client, each option needs its own clear and meaningful title that reflects its value.
The problem before: Service links in the deal showed only the default service title
To differentiate options, admins had to modify the service name itself: Service title (one-time payment), Service title (subscription) — cluttering the service catalog.
Solution — Title customization on the Offer Item level:
Bundles
A bundle is also an offer item, just with multiple services inside and common pricing.
Before: the admin manually processed the bundle payment and enrolled the client into each service separately. The entire cycle, including waiting time, could take up to 5 days.
Now: the client pays for all services in a single transaction and can start using them immediately.
Bundle purchase client flow
Team work
Granting access across roles
Admin — creates offers, sends them to clients, and delegates access
Service Host — sends clients the services they deliver. A Host’s access is dynamic and depends on whether they are actively hosting the service.
Sales Manager — sends offers they have access to. A Sales Manager’s access is determined by the Admin’s intention — until it’s revoked, they can send the offer to clients.
The problem: External tools (e.g., Notion) have no knowledge of the service team:
Offers must be manually created for each host, often across different business lines.
When a host changes, all relevant offers must be manually updated to remove services the team member no longer provides.
Solution — Dynamic “Share with Hosts” rule:
As a result, a Host’s access to an offer is set automatically, with services filtered accordingly. While a team member is hosting a service, the corresponding Offer Item remains available for them to send to their clients.
How Jeremy, as a host, sees the shared offer — only the services he is currently providing.
All company offers are now at a glance — giving full visibility into current pricing, team access, and effortless reuse without errors or wasted time.
The internal title helps the team understand the purpose of each offer, simplifying communication and reducing the risk of sending the wrong offer.
Validation
Approach
Formal usability testing wasn’t feasible. Validation was done through Customer Success, presenting new offer flows to admins and sales managers in realistic scenarios.
What was validated
Do admins understand how offers bundle multiple services and manage pricing?
Can they see which team members have access and control over each offer?
Do they feel confident sending offers to clients without risking errors?
Does the new flow reduce manual work compared to the previous external tools and copy-paste process?
Outcome
Admins confirmed the solution would reduce errors, save time, and give visibility and control over offers. Feedback also generated ideas for future enhancements.
Release & Impact
x5 sales cycle acceleration
Offer creation → client onboarding: from up to 5 days to <1 day.
~x5 sales scalability
Admins can send multiple offers without further manual work.
0 enrollment errors
Copy-paste of links and manual enrollment removed → no mistakes.
In scenarios where duplication was caused by pricing.