How I turned partner exceptions into one scalable activity model
Tripsome had outgrown a listing model built for children's activities. I redesigned it around how different businesses price, schedule, and sell. The work was later paused when the product direction changed.
Overview
Every new partner changed the rules.
Tripsome began with children's activities before expanding into tours, rentals, classes, sports, and ticketed experiences. The original listing system could not represent how all of these businesses operated, so supporting each new partner required another exception.
Problem
- Pricing, availability, and capacity were bundled inside sessions.
- Similar businesses often sold their experiences differently.
- New business models required hard-coded engineering changes.
- Each exception made the next change harder.
The old system
A three-step flow hid growing complexity
- The original flow looked simple, but activity sessions had gradually absorbed pricing, capacity, availability, age restrictions, and booking windows.
- As new requirements appeared, fields were added inside sessions instead of reconsidering the underlying model. Sessions had become mini-products of their own.
Research
Five businesses exposed the same system problem
Each partner request looked unique in isolation. Instead of solving them one at a time, I compared how existing and incoming partners priced, scheduled, and operated their activities.
I mapped the differences across pricing, capacity, and scheduling, then looked for the shared decisions underneath them.
From partner requests to system requirements
I stopped treating every request as another feature and traced the exceptions back to the way activities were structured.
Group recurring requests
I organized partner requirements around pricing, capacity, and scheduling.
Compare business models
Similar businesses often combined those rules in different ways.
Find the coupled decisions
Sessions were controlling rules that needed to change independently.
Define the system requirement
One model needed to combine flexible rules without another hard-coded flow.
The resulting comparison made the differences visible and explained why exceptions kept appearing.
| Business | Pricing | Capacity | Scheduling |
|---|---|---|---|
| Pottery Workshop | Per person | Fixed seats | Recurring classes |
| City Tour | Adult / child pricing | Large groups | Multiple departures |
| Play Center | Hourly | Flexible capacity | Open hours |
| Equipment Rental | Hourly / daily | Inventory-based | Flexible duration |
| Adventure Sports | Group packages | Minimum participants | Booking cutoffs |
Why the system needed to change
Existing activities could still be created, so usability alone was not enough reason to rebuild a core platform model.
The case for change was what the existing model prevented Tripsome from supporting.
- Every new business increased engineering dependency.
Supporting another pricing or scheduling model meant adding another exception.
- Tripsome could sell tickets, but not the complete experience.
Upgrades, extra time, and additional attempts often stayed offline because the booking model could not represent them.
- Future growth depended on a more flexible foundation.
New business and customer models should not require another platform redesign.
Solution
I redesigned the activity model, not just the form
I designed around partner decisions rather than the fields in the existing database. I separated what partners sell, how customers attend, when an activity is available, and how it is priced.
This created one guided flow that could adapt to different businesses without creating a separate setup for each one.
Existing activity model
Proposed activity model
What I designed
Four system decisions shaped the direction.
- A guided setup
Seven clear steps replaced complexity hidden inside sessions.
- Modular pricing
Per-person, group, and time-based rules appeared only when relevant.
- Independent availability
Scheduling and capacity could change without rebuilding pricing.
- Progressive disclosure
Common setups stayed short while advanced businesses retained flexibility.
Guide partners through setup
Seven steps organized the decisions from basic information to publishing without placing every setting on one screen.
Make pricing fit the business
Partners could combine customer, group, or time-based pricing without entering a separate flow for each business model.
Separate availability from pricing
Scheduling and capacity became independent decisions, so changing one did not force partners to rebuild the other.
Show advanced rules only when needed
Optional rules stayed hidden until a partner chose a setup that required them.
Design walkthrough
How the complete setup worked
The system carried the same structure across seven steps, from defining the activity to publishing it.
Basic information
Partners started by defining what the activity was and where it took place.
Photos
A focused step helped partners show the experience without mixing media with operational settings.
Availability
Partners chose how customers attended and when the activity was available. Advanced scheduling rules stayed optional.
Pricing
Three core fields covered the common setup. Customer, group, and time-based rules appeared only when the business required them.
Description
Customer-facing content remained separate from operational settings so partners could focus on explaining the experience clearly.
Additional details
Optional operational settings lived in their own step, keeping the core setup from becoming overwhelming.
Publishing
Partners could publish immediately, schedule publication, or choose when an activity should automatically come offline.
A safer way to migrate
I proposed running the old and new systems side by side. New activities would use the redesigned model while existing listings remained unchanged.
Older activities could then move gradually, allowing us to validate the architecture with real businesses before committing to a full migration.
Trade-offs
The difficult decisions were architectural
The interface became simpler only because the system made clearer decisions about where each rule belonged.
Lower cognitive load or easier editing?
I initially separated attendance and pricing methods into a dedicated step. That kept individual screens focused, but made later edits harder because related settings lived in different places.
I moved each decision into Pricing or Availability. The steps became slightly denser, but partners could understand and edit a business rule in one place.
Clear concepts or conflicting configuration?
Duration belongs in Availability, but hourly pricing also depends on it. Letting partners configure it in both places would create conflicting rules.
The flow adapted instead: time-slot activities defined duration in Availability and disabled hourly pricing. Other activities could use hourly pricing or provide an estimated duration.
Reflection
The work paused when product priorities shifted
The listing-system redesign was placed on hold before release, so there are no adoption or business-impact metrics.
Its value was in making the limits of the existing model visible, establishing a scalable direction, and giving the team a safer migration plan if the initiative resumes.
What I would do differently
- Confirm that a foundational rebuild aligns with the company's near-term direction before completing the full experience.
- Validate the highest-risk pricing and availability combinations before designing every setup step.
- Prototype the underlying data model with engineering before completing the interface.