1. Context & Why This Mattered
At Fresh Tracks Canada, pricing and margin decisions sat at the center of almost every critical workflow—from lead qualification to itinerary creation to revenue reporting. Despite this importance, the system that powered these decisions was not the Booking Management System (BMS), but a large, manually maintained Pricing & Margins (P&M) Excel file.
Over time, this spreadsheet evolved into a de facto source of truth. Sales teams relied on it during live customer calls to estimate prices. Product teams depended on it to analyze seasonal pricing trends and define margin thresholds. Finance referenced it to understand margin expectations.
The problem wasn’t just that Excel was manual—it was that core business decisions were happening outside the product, forcing teams to constantly switch tools, re-enter data, and reconcile inconsistencies.
This became especially visible when leads were qualified. Sales would estimate prices using Excel, but once a lead moved forward, they had to restart everything inside BMS. Context was lost, effort was duplicated, and momentum dropped at a critical conversion moment.
The goal of this project was not simply to “remove Excel,” but to bring pricing and margin intelligence into the system of record, so teams could work continuously, confidently, and with less risk. Image to place after this section - Problem framing / ecosystem
2. The Problem: Broken, Fragmented Workflows
Sales workflow (Before)
This problem didn’t show up as a single broken screen. It showed up as daily friction, silent errors, and workarounds that teams had learned to tolerate.
Sales: Quoting Under Cognitive Pressure
For Sales, pricing was not just about numbers — it was about performing mental calculations while talking to a customer.
When a lead came in, Sales agents had to:
Open the P&M Excel file mid-call
Scan through dense tables with multiple seasons, trip classes, and traveller compositions
Infer which price was representative rather than explicitly marked
Ensure they were not quoting below an invisible margin threshold
All of this happened:
While answering customer questions
Without system guardrails
With no confidence that the number they gave would hold later
If a customer pushed back on price, Sales often had to:
Pause the conversation
Manually search for alternate dates in Excel
Re-estimate pricing on the fly
Once the lead was qualified, none of this thinking carried forward. Sales had to restart in BMS, recreating trips and re-deriving decisions they had already made.
Net effect:
Longer calls
Higher cognitive load
Lower confidence in quoted numbers
Drop-offs after qualification when momentum was lost

Product workflow (Before)
For Product teams, pricing work was less about calculation and more about pattern detection.
To price a single trip, Product had to:
Cost the trip inside BMS
Export large datasets into Excel
Use conditional formatting to visually scan for price variance across dates
Decide where seasons should split based on those patterns
Pick representative costs that would hold across multiple traveller compositions
Calculate minimum and target margins manually
Re-enter the same decisions back into BMS
This workflow had several hidden problems:
The system couldn’t explain decisions — only the spreadsheet could
Every export/import introduced the risk of mismatched values
Small mistakes (wrong representative date, wrong margin) were hard to catch later
Historical context was lost once data was re-entered
Over time, Product became caretakers of a fragile process rather than owners of a scalable system.

Finance & Operations: No Reliable Lineage
Finance didn’t interact with the P&M file daily, but they inherited its consequences.
Because pricing and margin logic lived outside the system:
There was no clear lineage of how a final price was reached
Margin changes over time were hard to trace
It was difficult to distinguish intentional discounts from process errors
This reduced trust in downstream reporting and made it harder to answer simple questions like:
“Why was this trip priced this way?”
The Core Problem
The real issue wasn’t Excel.
It was that:
Critical decisions were happening outside the product
Systems couldn’t explain or defend those decisions
Teams were forced to rely on memory, expertise, and workarounds
The product wasn’t supporting how people actually worked — it was asking them to compensate for its gaps.
3. What Was at Risk
While exact metrics weren’t available, the risks were clear and repeatedly surfaced in stakeholder conversations:
Business risk: Inconsistent pricing and margin application could directly impact profitability.
Sales risk: Slow and mentally taxing qualification increased the likelihood of drop-offs after qualification.
Operational risk: Margin history and pricing decisions were difficult to trace or explain.
Product risk: A growing amount of time was spent maintaining spreadsheets instead of improving the product.
This reframed the problem from “UX inefficiency” to system reliability and decision integrity.4. My Role
I led the end-to-end design for Pricing & Margins integration across Phase 1 and Phase 2.
4. My Role
I led the design end-to-end across Phase 1 and Phase 2 of the Pricing & Margins integration.
My responsibilities included:
Framing the problem beyond surface-level UI issues
Breaking down complex workflows across teams
Shadowing Product and Sales users in real scenarios
Designing interactions that balanced flexibility with guardrails
Validating concepts with stakeholders and users
Ensuring design decisions were technically feasible
I partnered closely with the PM on discovery and prioritization, while independently driving design direction, user validation, and system thinking.
5. Design Challenges & Tensions
This project involved navigating several competing forces:
Speed vs accuracy: Sales needed quick answers; Finance needed margin safety.
Flexibility vs control: Users wanted Excel-like freedom without risking data integrity.
Power vs usability: Product teams needed to work with massive datasets without overwhelming interfaces.
MVP vs reality: Edge cases were common, not rare.
Every design decision had to respect the fact that pricing is both a business lever and a trust boundary.
6. Discovery Insight: Learning from Excel
While shadowing Product users, I noticed something important: Excel wasn’t just a workaround—it was an expert tool.
Product teams relied heavily on conditional formatting across large datasets (often spanning a full year and multiple traveller compositions) to visually identify pricing variance. This allowed them to quickly spot where seasons should split and where margins needed adjustment.
The key insight was not to eliminate this behavior, but to support it inside the system.
The design goal became:
Preserve expert judgment, but remove manual dependency.
7. Key Design Decisions
This project required designing how pricing decisions are made, not just where numbers are shown. Each decision below emerged from real failure modes observed in existing workflows.
1. Preserving Excel’s Visual Intelligence — Without Preserving Excel
The problem this solved
Product teams were not using Excel because they preferred spreadsheets — they were using it because Excel allowed them to see patterns across large datasets quickly.
In BMS, pricing data was fragmented:
Costs were viewed one class or date at a time
Price variance across dates was difficult to detect
Identifying season boundaries required exporting data
Without a comparable visual signal, moving pricing fully into BMS would have slowed expert users rather than helped them.
The decision
Instead of abstracting pricing into simplified summaries, I designed a dense, comparison-friendly pricing table inside BMS that:
Displayed all trip classes together
Used conditional formatting per class, not globally
Made price variance visually obvious without calculation
Why this mattered
This allowed Product users to continue using visual judgment — the same skill they had built in Excel — while keeping data inside the system.
What we intentionally didn’t do
We didn’t collapse pricing into single averages
We didn’t hide complexity behind charts
We didn’t force recalculation just to understand variance
The system became a place to reason, not just to store values.

2. Making Season Splitting a Controlled, First-Class Interaction
The problem this solved
Season splitting was one of the most error-prone steps in the entire pricing workflow. In Excel, users:
Manually inferred where seasons should change
Rebuilt seasons after exporting data
Re-entered decisions into BMS with no safety net
Any mistake required restarting large parts of the process.
The decision
I introduced season splitting directly inside BMS as a deliberate interaction:
Users could select date ranges visually
Split seasons without re-running pricing calculations
Apply representative costs across traveller compositions automatically
This decoupled analysis from recalculation.
Why this mattered
Users could explore different season boundaries without fear of breaking data or losing work.
What we intentionally didn’t do
We didn’t auto-split seasons based on algorithms
We didn’t assume a “correct” season structure
We didn’t require recalculation for exploratory actions
This respected the fact that season definition is a judgment call, not a formula.

3. Designing Undo as a Safety Mechanism, Not a Convenience Feature
The problem this solved
Season splits affected:
Pricing logic
Margin calculations
Downstream Sales behavior
Without a way to undo, users were forced to be overly cautious — slowing work and avoiding exploration.
Early feedback suggested undo was unnecessary and could be treated as scope creep.
The decision
I argued that any high-impact pricing action must be reversible.
Undo was designed as:
A first-class interaction
Explicit and discoverable
Safe across traveller compositions
Why this mattered
Undo reduced the cost of mistakes to near zero. Users could:
Experiment faster
Correct errors without restarting
Trust the system during complex decisions
User validation
Product users explicitly confirmed that undo reflected real-world workflows, not edge cases.
What we intentionally didn’t do
We didn’t hide undo behind confirmation modals
We didn’t treat errors as exceptional behavior
We didn’t rely on “be careful” as a UX strategy

4. Designing Guardrails Without Blocking Sales
The problem this solved
Sales needed flexibility during conversations, but:
Pricing below margin thresholds created business risk
Margin rules were invisible during qualification
Excel offered no guardrails — only guidelines
Blocking Sales outright would have slowed deals. Allowing unlimited flexibility would have increased risk.
The decision
Margin thresholds were embedded into the system as visible constraints, not hard stops:
Sales could see when pricing approached risk boundaries
Product-defined targets and minimums guided decisions
Final enforcement happened downstream, not mid-conversation
Why this mattered
This balanced:
Sales autonomy
Financial safety
Decision transparency
What we intentionally didn’t do
We didn’t fully lock pricing
We didn’t hide margin logic from Sales
We didn’t rely on policy documents to enforce behavior

5. Optimizing for Real-World Data Scale, Not Demo Scenarios
The problem this solved
Pricing tables often spanned:
A full year of dates
Multiple traveller compositions
Several trip classes
Designs that worked for small datasets failed immediately at real scale.
The decision
I designed interactions assuming:
Large, dense datasets
Frequent scanning rather than precise reading
Repeated comparison over exact input
This influenced:
Table density
Visual hierarchy
Interaction affordances
Why this mattered
The system remained usable under real operational load, not just ideal conditions.
8. Technical Collaboration
To de-risk implementation:
I iterated designs in Builder.io
Explored frontend logic for conditional formatting
Worked through formulas with engineers
Shared libraries and implementation references
This ensured design intent translated cleanly into production.
9. Validation & Early Signals
The solution was validated through:
Walkthroughs with Product and Sales SMEs
Iterative feedback on real pricing scenarios
Pre-production prototype testing
Feedback consistently highlighted:
Faster decision-making
Reduced need to leave the system
Increased confidence in pricing and margin setup
10. Impact (Directional)
While exact metrics weren’t available, early signals suggested:
Fewer workflow resets between qualification and trip creation
Reduced cognitive load during Sales calls
Lower error risk from manual re-entry
Improved confidence in margin decisions
Assumed before → after
Before: Salesforce → Excel → BMS (restart)
After: Continuous workflow inside BMS
11. What I’d Improve if This Scaled
If this system scaled further, I’d focus on:
Making margin history explorable over time
Instrumenting analytics around qualified-lead drop-offs
Stress-testing performance for larger datasets
Designing clearer escalation paths near margin thresholds
12. Reflection
This project reinforced that:
Removing spreadsheets is about respecting expert workflows, not simplification
Influence often comes from validation, not authority
Decision-support systems must prioritize clarity, reversibility, and trust



