Rebuilding Pricing & Margin Decisions Inside the Core Booking System

Rebuilding Pricing & Margin Decisions Inside the Core Booking System

Rebuilding Pricing & Margin Decisions Inside the Core Booking System

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

Available for freelance

Back to top

Back to top

Let's create
something
extraordinary
together.

Let’s make an impact

Avatar of the website author

Ishan Deshmukh

Senior Product Designer

Available for freelance

Back to top

Back to top

Let's create
something
extraordinary
together.

Let’s make an impact

Avatar of the website author

Ishan Deshmukh

Senior Product Designer

Available for freelance

Back to top

Back to top

Let's create
something
extraordinary
together.

Let’s make an impact

Avatar of the website author

Ishan Deshmukh

Senior Product Designer