Partner Booking Portal
Reducing booking friction by 50% through clearer workflows and communication systems.
My Role
UX Designer (while working as B2B Tour Coordinator)
Timeline
12 weeks
Collaborated with
Inbound Tour Coordinators
Outbound Tour Coordinator
Vancouver Royal Tours
Vancouver Royal Tours operates guided tours across the Canadian Rockies and Lower Mainland BC.
Context
At Vancouver Royal Tours, partner booking requests were managed primarily through email. Coordinators manually interpreted requests, checked availability, issued invoices, and entered information across multiple systems.
Problem
Email requests often arrived in inconsistent formats with missing or ambiguous information. Coordinators frequently had to interpret requests, follow up for clarification, and manually re-enter information, creating delays and increasing the risk of errors.
Affected workflow:
Interpret -> Clarify -> Process -> Re-enter
Average request handling time:
~ 15 min/request.
Solution and Impact
Partner Portal.
Designed a structured booking portal that standardized information input and reduced back-and-forth communication.
Workflow Efficiency
~15 min → ~4 min (73% faster)
Reduced manual interpretation and follow-ups.
Problem
How Booking Workflow Worked Before
Booking requests were handled through fragmented email workflows and manual coordination.
The workflow process was email-based, unstructured and manual.
Booking requests often required multiple clarification loops before they could be processed.
Repeat for missing or unclear information
Requests arrive
Emails, attachments, and inconsistent terminology.
Interpret request
Coordinators manually infer missing context.
Clarify details
Back-and-forth emails delay processing.
Re-enter information
Data manually entered into ERP and spreadsheets.
Process booking
Availability, invoicing, and partner communication.
Operational Impact
~5 minutes
Spent understanding each request
Frequent clarification emails
Back-and-forth causes delays and context switching
Downstream operational delays
Errors and delays affected partners and internal teams.
Unstructured communication forced coordinators to spend time interpreting information instead of processing bookings.
Contextual Inquiries
Observing to Validate
What I experienced pointed to deeper issues, therefore, I observed how my colleagues handled real booking requests to see if this was a system-wide problem.
Who I spoke with
2 inbound coordinators
1 outbound agent
(proxy for partners)
How I did it
Contextual inquiry sessions with real booking scenarios and follow-up questions.
Below are the key highlights of the interviews:
What's happening
Key Observations
Workarounds became normalized
Information relied heavily on memory
Staff operated with high fear of mistakes
Why it's happening
What We Uncovered
Communication was inconsistent and ambiguous
Information was fragmented across email threads and attachments
Staff manually interpreted and re-structured data before action
What it causes
Impact on workflow
Higher error risk and rework
Slower decision making and operational drag
Downstream impact on partners, customers, and teams
What we could do
Opportunity
Communication was inconsistent and ambiguous
Information was fragmented across email threads and attachments
Staff manually interpreted and re-structured data before action
Key Insight
The root issue is the system that relies on the people to interpret and structure messy information.
Solution Brainstorming
From Options to Impact
To recap, here was the key problem that surfaced from the research:
“Unstructured partner inputs forced internal teams to manually interpret and rebuild every booking.”
I explored two directions to address the operational issues uncovered during research.
Google Forms
PROS
Low cost
Quick to implement
Familiar workflow
CONS
Limited handling for complex logic
Still dependent on email workflows
Fragmented experience
Partner Portal
PROS
Structured partner input
Centralized workflow
Scalable foundation
CONS
Higher implementation effort
Requires engineering support
Adoption and integration risk
CHOSEN SOLUTION
Why Partner Portal?
While Google Forms improved data collection, it still relied heavily on fragmented email workflows. The Partner Portal addressed the problem at the source by standardizing inputs, centralizing communication, and reducing manual interpretation before bookings reached internal teams.
Prioritized long-term scalability and structured data over short-term operational convenience.
Flows + Information Architecture
Designing the Workflow System
Since the core issue was workflow inefficiency, I designed two connected flows: one for partners submitting requests, and another for coordinators reviewing them internally.
Why design 2 flows instead of one?
It was to:
Ensure consistency between what is submitted an how it’s processed
Design a system that works holistically
2 complementary flows ensure end-to-end consistency and a seamless experience.
Flow 1
Requesting a booking
(Partner side)
Partner Portal
Flow 2
Review and processing a booking
(Internal side)
FLOW 1: Requesting a Tour Booking
In this flow, the main feature was the booking form. However, it's important to note that different partner regions meant different pricing, inclusions, and payment expectations.
Therefore, I focused on defining a complete and accurate logic for a single partner type first.
1
Inputs & Constraints
What we had to handle
Partner Type
📍 BC Based
🌍 Outside BC
🇺🇸 US Based
🇰🇷 Korea Based
Key Variables
💱 Currency:
CAD
USD
📅 Tour Type:
3N
4N
5N
⚙️ Optional Add-ons:
Meal Plan
Snow Coach
Gondola
Different partner regions = different pricing, inclusions, and payment expectations
2
Form Logic System
Step-by-step flow with conditional logic
1
2
3
4
Basics
Request date (auto-filled)
Agent into (auto-filled)
Reduced maual input by pre-filling known data
Core Booking Details
Tour type (dropdown)
Price (auto-calculated)
Customer info
# of people
Occupancy
Meeting location
Sending locatiom
Flight info (conditional)
Standardized inputs replaced inconsistent email formats
Conditional Add-ons
🍽️ Meal Plan
Yes / No / Undecided
# of people
Payment method
Include in invoice
Pay cash onsite
🚍 Snow Coach
Yes / No / Undecided
# of people
Payment method
Include in invoice
Pay cash onsite
🚠 Gondola & Lunch
Yes / No / Undecided
# of people
Payment method
Include in invoice
Pay cash onsite
Optional services introduced nested logic, increasing form complexity
Review
Editable summary of all details
Users can make changes before confirmation
Confirmation
Request submitted
Status tracking enabled
Replaced back-and-forth confirmation emails
FLOW 2: Reviewing a Booking
In this flow, I focused on cutting down the amount of steps required to review and approve a request as shown below.
Old workflow: Review Booking Request
BEFORE
Total # of steps: 15
AFTER
New workflow: Review Booking Request
Total # of steps: 7
Co-designing with AI
Fleshing out Designs
Ropid Prototyping Workflow
I used AI-assisted prototyping tools to rapidly explore layout directions and interaction ideas. Generated concepts were refined manually in Figma to improve hierarchy, readability, and operational usability.
1
Prompt in AI
“Make me a portal with the given flow and features.”
2
Refine & Iterate
Add more context (IA, content)
iterate through trial & error
3
Polish in Figma
Fin-tune UI hierarchy, and content
Validate with users
These 3 steps weren't linear, and there were indeed a lot of trial and errors in the process. Just to highlight a few:
1
Making Key Information Easier to Scan
Prioritized key information to improve scanability and readability
BEFORE
AFTER
Why this change?
Users struggled to quickly identify key information due to poor hierarchy.
What changed?
Introduced clearer grouping, spacing, and emphasis on key fields.
2
Aligning Flight Details with How Coordinators Actually Work
Reorganized and simplified inputs to better match how coordinators process flight details
BEFORE
AFTER
Why this change?
Tour Coordinators understand certain information differently and need a quick and easy scan way to view them.
What changed?
Simplified input titles and descriptions, got rid of unnecessary inputs while adding in sections that indicate multiple flight information.
Removed redundant “Airline” field since flight number already contains this information.
Airport codes are more accurate than names of cities.
There can be more than 1 flight information that we need.
Simplified input titles for easier scan
Testing and Iteration
Adding Layers with Usability
User Testing
Moderated usability tests were conducted with 3 internal users (tour coordinators) who regularly book and review partner booking requests.
Participants
3 internal users
Duration
15-20 mins per session
Tasks
Inbound: Review request → Approve request
Outbound: Review details → Request and submit booking
Method
Think-aloud + post-task interview
From the testings, there were 2 main problems that surfaced:
1
Room information was consistently misinterpreted
Users were unsure what “Room Type: Double” meant.
Participant 1 & 3
Does ‘Double’ mean
one bed or just two people?”
Ambiguity in words (terminology) led to hesitation and uncertainty.
2
The system did not support “in-between” actions
Although users wanted to send a message and hold the request, there was no action to do that.
Participant 2 & 3
I’d probably ask them first.. but what do I click here?”
Missing “Send and pend” action caused confusion and broke the flow.
Iterations
Based on the testing findings above, I iterated on key pain points to better align the system with real operational workflows.
1
Clarified Room Information & Added Room Summary
Replaced ambiguous “Room Type” with “Occupancy” and added a total room summary for instant clarity.
BEFORE
AFTER
Why this change?
“Room Type” was interpreted inconsistently (bed vs. occupancy)
What changed?
Replaced 'Room Type' → 'Occupancy'
Added helper text (bed not guaranteed)
Added total room summary
Impact
Eliminates ambiguity around room type vs occupancy
Instant visibility of total rooms needed
Faster decision-making with less back-and-forth
2
Added “Pend & Send” Action to Support Real Workflows
Introducted a way to send a message and hold the request for clarification before making a decision.
BEFORE
AFTER
Why this change?
Users needed to ask for clarification before approving, but had no way to communicate and hold the request.
What changed?
Added “Pend & Send” button so users can request info and pause the request without rejecting it.
Impact
Enabled in-flow communication with partners
Requests can be held without losing context
Smoother workflow and more confident decisions
Final Design Snapshot
Royal Tours Partner Portal
Following usability testing and iterations, the final designs focused on reducing ambiguity, improving request quality, and simplifying internal operations.
End-to-end flows
Log in
Log in
Fill out Request Form
Select Request
Review Request
Automate Invoice
Done!
Done!
Partner-facing: Sending a Request
Internal-facing: Review and Confirming a Request
Key Design Decisions
Structured quantity inputs separate Adults and Children
Radio buttons enforce single payment selection
Pricing details available on demand via tooltip
Inline validation catches missing information before submission.
Convert requests into a single structured layout optimized for scanning.
Standardized labels replaced ambiguous terminology.
Invoice information auto-populates using request and partner data.
Clarifying Optional Tour Selection
Preventing Missing Information
Standardized Request Review
Removing Payment Vocabulary Confusion
Automating Invoice Creation
Pilot Validation
What the MVP Proved
To sum up, here's what the MVP proved to show: We saw a significant reduction in cycle duration and manual effort. Below is the breakdown.
What improved
70% faster cycle time
Fewer clarification emails
Reduced cognitive load
Structured inputs and centralized workflows reduced booking processing time from ~15 to ~4 minutes by eliminating manual interpretation and unnecessary steps.
~15 min
per booking
Multiple systems, manual interpretation, and re-entry
~4 min
per booking
Structured input, streamlined flow, fewer muanl steps
Before (current workflow)
After (MVP workflow)
Implementation Realities
What Implementation Required
While the MVP showed strong potential, several implementation constraints needed to be addressed. Those constraints were:
ERP Integration Dependency
Full implementation depended on ERP collaboration to support booking synchronization, validation, and operational consistency across existing systems.
Organizational Adoption & Change Management
Success depended on both internal teams and partner agencies adopting a more structured workflow, requiring onboarding, operational alignment, and trust in a new process.
Resource Investment & Prioritization
Rolling out the system would require organizational investment across engineering support, onboarding, and operational coordination to sustain long-term adoption.
While the MVP validated the workflow improvements, scaling the solution required broader organizational alignment and operational readiness beyond the pilot stage.
Takeaways and Learnings
What I learned from This Project
This project definitely felt unlike any other projects. To wrap up, here are some of my takeaways and learnings.
Adoption is a product challenge
Usability alone isn't enough. Change management and trust matter just as much.
Think beyond the interface
Successful products solve user problems and fit within the organizational context.
FINAL CONCLUSION
This project began as an attempt to reduce workflow friction, but evolved into a lesson in designing for real organizational environments.
Beyond usability, I learned that successful operational systems depend on structured workflows, stakeholder alignment, and readiness for adoption.
