Back
The Complex Problem of Reservation Rescheduling
The Complex Problem of Reservation Rescheduling
The Complex Problem of Reservation Rescheduling
What is Lavanda?
What is Lavanda?
What is Lavanda?
Lavanda is an award-winning property technology SaaS platform. The flagship product is cutting-edge Property Management Software (PMS) that has transformed the landscape of short-stay rentals. Due to it’s success Lavanda are expanding into built-to-rent (BTR), long-stay accommodations, and purpose-built student housing (PBSA).
As well as working on the PMS's various features, I design direct booking websites that allow guests to create bookings, built from the ground up our white-labeled application portal and email templating, all B2B2C.
Lavanda is an award-winning property technology SaaS platform. The flagship product is cutting-edge Property Management Software (PMS) that has transformed the landscape of short-stay rentals. Due to it’s success Lavanda are expanding into built-to-rent (BTR), long-stay accommodations, and purpose-built student housing (PBSA).
As well as working on the PMS's various features, I design direct booking websites that allow guests to create bookings, built from the ground up our white-labeled application portal and email templating, all B2B2C.
Lavanda is an award-winning property technology SaaS platform. The flagship product is cutting-edge Property Management Software (PMS) that has transformed the landscape of short-stay rentals. Due to it’s success Lavanda are expanding into built-to-rent (BTR), long-stay accommodations, and purpose-built student housing (PBSA).
As well as working on the PMS's various features, I design direct booking websites that allow guests to create bookings, built from the ground up our white-labeled application portal and email templating, all B2B2C.
The brief
The brief
Imagine you're in charge of running an 1800-room building for both short-stay vacation rentals and long-stay homes. You'd think that a basic action like moving a booking should be a breeze, right? Well, not quite.
At Lavanda, we found ourselves facing a considerable challenge in this seemingly simple task. Let me take you through the journey of how we tackled this issue and transformed it for our customers.
Imagine you're in charge of running an 1800-room building for both short-stay vacation rentals and long-stay homes. You'd think that a basic action like moving a booking should be a breeze, right? Well, not quite.
At Lavanda, we found ourselves facing a considerable challenge in this seemingly simple task. Let me take you through the journey of how we tackled this issue and transformed it for our customers.
Imagine you're in charge of running an 1800-room building for both short-stay vacation rentals and long-stay homes. You'd think that a basic action like moving a booking should be a breeze, right? Well, not quite.
At Lavanda, we found ourselves facing a considerable challenge in this seemingly simple task. Let me take you through the journey of how we tackled this issue and transformed it for our customers.
Current limitations
Current limitations
Our inability to move bookings between different unit types
Our inability to move bookings between different unit types
Moving a booking from one unit to another might sound like a straightforward operation, but it came with a massive restriction. Especially during the peak season, when bookings were pouring in, we were hamstrung by the fact that our system could could only shift bookings between units of the same type.
To grasp the significance of this issue, it's essential to understand unit types. In large properties, units with identical layouts and amenities are grouped into unit types, essentially sharing a blueprint. There may be 10 units, all under the same unit type.
Moving a booking from one unit to another might sound like a straightforward operation, but it came with a massive restriction. Especially during the peak season, when bookings were pouring in, we were hamstrung by the fact that our system could could only shift bookings between units of the same type.
To grasp the significance of this issue, it's essential to understand unit types. In large properties, units with identical layouts and amenities are grouped into unit types, essentially sharing a blueprint. There may be 10 units, all under the same unit type.
Moving a booking from one unit to another might sound like a straightforward operation, but it came with a massive restriction. Especially during the peak season, when bookings were pouring in, we were hamstrung by the fact that our system could could only shift bookings between units of the same type.
To grasp the significance of this issue, it's essential to understand unit types. In large properties, units with identical layouts and amenities are grouped into unit types, essentially sharing a blueprint. There may be 10 units, all under the same unit type.
What's the impact on Lavanda and customers?
What's the impact on Lavanda and their customers?
What's the impact on Lavanda and customers?
30
30
service requests to engineers a week
service requests to engineers a week
service requests to engineers a week
80%
80%
Occupancy often means no available units of that unit type
Occupancy often means no available units of that unit type
Occupancy often means no available units of that unit type
3.5 Hrs
3.5 Hrs
customer wait for a booking move to be actioned meaning potentially lost revenue
customer wait for a booking move to be actioned meaning potentially lost revenue
customer wait for a booking move to be actioned meaning potentially lost revenue
Design Process
Design Process
I began by collecting briefs through client calls, Lavanda Guest Experience Team and Account Manager interviews to get a core understanding of the various needs across different verticals.
I began by collecting briefs through client calls, Lavanda Guest Experience Team and Account Manager interviews to get a core understanding of the various needs across different verticals.
I began by collecting briefs through client calls, Lavanda Guest Experience Team and Account Manager interviews to get a core understanding of the various needs across different verticals.
These points came out as the key issues our users have today:
Moves at any point in the journey
Between unit types
Control on pricing
Updating all linked items such as services, check out cleans, emails.
Moves at any point in the journey
Between unit types
Control on pricing
Updating all linked items such as services, check-outs, cleans, emails.
These points came out as the key issues our users have today:
Moves at any point in the journey
Between unit types
Control on pricing
Updating all linked items such as services, check out cleans, emails.
Prototype One - Internal testing with AM’s and super users
From this I learnt that:
Not all bookings changes will be started from the bookings calendar, therefore the design needs to work when being launched from multiple places within the PMS. The UI will need to be as reusable as possible.
It needs to be clear if the booking has already started and the guest has checked in prior to the move happening.
What is the state of the room that they want to move the booking too? Is it clean or still waiting for housekeeping?
Armed with this, I iterated on the design reviewing it continuously with our Chief Product Officer and presented the next prototype to customers.
Prototype One - Internal testing with AM’s and super users
From this I learnt that:
Not all bookings changes will be started from the bookings calendar, therefore the design needs to work when being launched from multiple places within the PMS. The UI will need to be as reusable as possible.
It needs to be clear if the booking has already started and the guest has checked in prior to the move happening.
What is the state of the room that they want to move the booking too? Is it clean or still waiting for housekeeping?
Armed with this, I iterated on the design reviewing it continuously with our Chief Product Officer and presented the next prototype to customers.
Prototype One - Internal testing with AM’s and super users
From this I learnt that:
Not all bookings changes will be started from the bookings calendar, therefore the design needs to work when being launched from multiple places within the PMS. The UI will need to be as reusable as possible.
It needs to be clear if the booking has already started and the guest has checked in prior to the move happening.
What is the state of the room that they want to move the booking too? Is it clean or still waiting for housekeeping?
Armed with this, I iterated on the design reviewing it continuously with our Chief Product Officer and presented the next prototype to customers.
Prototype Two - Remote external testing, 5 customers.
These users were more detailed in their approach to the prototype and concerns they had seen less experienced colleagues make in the past.
More information about the destination unit (is it fit for this booking, will number of guests fit etc.)
Handling of payments and refunds due to pricing changes needs to be seamless
Move between buildings
They often already have a unit in mind to more the guest to (prior research to the room move via multi-calendar)
Bad UI: users couldn't identify how to select a new unit type with 4/5 missing the pre-filled dropdown field.
A question that everyone asked: why not a simple drag-and-drop feature in the booking calendar?
We had already internally discussed this and due to technical limitations with our existing calendar and a plan to rebuild it. Investing significant time into a drag-and-drop solution was beyond our current scope.
Prototype Two - Remote external testing, 5 customers.
These users were more detailed in their approach to the prototype and concerns they had seen less experienced colleagues make in the past.
More information about the destination unit (is it fit for this booking)
Handling of payments and refunds due to pricing changes needs to be seamless
Move between buildings: They often already have a unit in mind to more the guest to (prior research to the room move via multi-calendar)
Bad UI: users couldn't identify how to select a new unit type with 4/5 missing the pre-filled dropdown field.
A question that everyone asked: why not a simple drag-and-drop feature in the booking calendar?
We had already internally discussed this and due to technical limitations with our existing calendar and a plan to rebuild it. Investing significant time into a drag-and-drop solution was beyond our current scope.
Prototype Two - Remote external testing, 5 customers.
These users were more detailed in their approach to the prototype and concerns they had seen less experienced colleagues make in the past.
More information about the destination unit (is it fit for this booking, will number of guests fit etc.)
Handling of payments and refunds due to pricing changes needs to be seamless
Move between buildings
They often already have a unit in mind to more the guest to (prior research to the room move via multi-calendar)
Bad UI: users couldn't identify how to select a new unit type with 4/5 missing the pre-filled dropdown field.
A question that everyone asked: why not a simple drag-and-drop feature in the booking calendar?
We had already internally discussed this and due to technical limitations with our existing calendar and a plan to rebuild it. Investing significant time into a drag-and-drop solution was beyond our current scope.
Iterate, itertate, iterate
Iterate, itertate, iterate
A redesign
I refined the design fixing other UI issues identified in user testing along turning it into a full-screen modal to give users full visibility of steps and the booking in a style that works for multiple starting points.
On trying to solve the biggest issue, 'The design for selecting a NEW unit type wasn’t clear with it failing 4/5 times.' we changed the design from pre-filled drop downs to asking the user to start that selection from scratch.
These changes achieved better user testing results but in line with our evolving design system and mobile-first design principles, we iterated further.
A redesign
I refined the design fixing other UI issues identified in user testing along turning it into a full-screen modal to give users full visibility of steps and the booking in a style that works for multiple starting points.
On trying to solve the biggest issue, 'The design for selecting a NEW unit type wasn’t clear with it failing 4/5 times.' we changed the design from pre-filled drop downs to asking the user to start that selection from scratch.
These changes achieved better user testing results but in line with our evolving design system and mobile-first design principles, we iterated further.
A redesign
I refined the design fixing other UI issues identified in user testing along turning it into a full-screen modal to give users full visibility of steps and the booking in a style that works for multiple starting points.
On trying to solve the biggest issue, 'The design for selecting a NEW unit type wasn’t clear with it failing 4/5 times.' we changed the design from pre-filled drop downs to asking the user to start that selection from scratch.
These changes achieved better user testing results but in line with our evolving design system and mobile-first design principles, we iterated further.
Unit selection default view for first round of user testing which had the current unit selected
After user testing, showing the current unit and a primary CTA to start adding the new unit
Changing again
By this point I had gone through multiple prototypes.
During our squad kick off to review the work, and spread the knowledge I had learnt so far, we had other suggestions which would still encapsulate many of the learnings I had from the previous user tests.
We compressed the designs into a side panel, this allowed it to be used easily on both mobile and desktop.
It allowed us to show useful information about unit availability when opened from the calendar or the booking if opened directly in a reservation.
We made it feel less cluttered by using cards as a stepper to lead people through, this gave them context and length, but made sure the view wasn't to high on cognitive load.
The result? A mobile-friendly, user-centric solution that provides feedback on previous decisions, allowing for easy adjustments and adaptable flows based on booking specifics which you can see below
Changing again
By this point I had gone through multiple prototypes.
During our squad kick off to review the work, and spread the knowledge I had learnt so far, we had other suggestions which would still encapsulate many of the learnings I had from the previous user tests.
We compressed the designs into a side panel, this allowed it to be used easily on both mobile and desktop.
It allowed us to show useful information about unit availability when opened from the calendar or the booking if opened directly in a reservation.
We made it feel less cluttered by using cards as a stepper to lead people through, this gave them context and length, but made sure the view wasn't to high on cognitive load.
The result? A mobile-friendly, user-centric solution that provides feedback on previous decisions, allowing for easy adjustments and adaptable flows based on booking specifics which you can see below
Changing again
By this point I had gone through multiple prototypes.
During our squad kick off to review the work, and spread the knowledge I had learnt so far, we had other suggestions which would still encapsulate many of the learnings I had from the previous user tests.
We compressed the designs into a side panel, this allowed it to be used easily on both mobile and desktop.
It allowed us to show useful information about unit availability when opened from the calendar or the booking if opened directly in a reservation.
We made it feel less cluttered by using cards as a stepper to lead people through, this gave them context and length, but made sure the view wasn't to high on cognitive load.
The result? A mobile-friendly, user-centric solution that provides feedback on previous decisions, allowing for easy adjustments and adaptable flows based on booking specifics which you can see below
The final prototype
The final prototype
Launch Plan
Launch Plan
Unfortunately I left Lavanda before I could see the project materialise but I worked closely with some of our largest customers including GreyStar who manage almost 1,000,000 units globally and engineering and product team including the Product Manager, CPO and Squad leads.
Based on the ‘golden halo’ design, we broke the launches down into chunks, prioritising the elements of the move between the necessary, want nows and needs later. We also stripped out upon first launch, changes that could be made currently to the booking such as changing the pricing from a fixed date. This allowed the team to deliver the most value to the most customers upon first launch, as well as gather feedback and make any iterations required in the next releases.
Some elements in the prototype are not available due to reliances on other teams who have not yet built out the feature but we know it is on the roadmap. This has ensured that as that feature becomes available, the requirement to add it to the ‘move a booking flow’ is part of the initial launch.
Unfortunately I left Lavanda before I could see the project materialise but I worked closely with some of our largest customers including GreyStar who manage almost 1,000,000 units globally and engineering and product team including the Product Manager, CPO and Squad leads.
Based on the ‘golden halo’ design, we broke the launches down into chunks, prioritising the elements of the move between the necessary, want nows and needs later. We also stripped out upon first launch, changes that could be made currently to the booking such as changing the pricing from a fixed date. This allowed the team to deliver the most value to the most customers upon first launch, as well as gather feedback and make any iterations required in the next releases.
Some elements in the prototype are not available due to reliances on other teams who have not yet built out the feature but we know it is on the roadmap. This has ensured that as that feature becomes available, the requirement to add it to the ‘move a booking flow’ is part of the initial launch.
Unfortunately I left Lavanda before I could see the project materialise but I worked closely with some of our largest customers including GreyStar who manage almost 1,000,000 units globally and engineering and product team including the Product Manager, CPO and Squad leads.
Based on the ‘golden halo’ design, we broke the launches down into chunks, prioritising the elements of the move between the necessary, want nows and needs later. We also stripped out upon first launch, changes that could be made currently to the booking such as changing the pricing from a fixed date. This allowed the team to deliver the most value to the most customers upon first launch, as well as gather feedback and make any iterations required in the next releases.
Some elements in the prototype are not available due to reliances on other teams who have not yet built out the feature but we know it is on the roadmap. This has ensured that as that feature becomes available, the requirement to add it to the ‘move a booking flow’ is part of the initial launch.
How we would measure success
How we would measure success
Before we began the work we gathered specific KPIs which we plan to improve but also put in place time to build out help guides as we do for all of our features with the Customer Success team.
We expect to see:
A 95% reduction in move requests during Summer (1st July - 31st August)
A 15% increase in availability and occupancy across all revenue generating units compared to the expected summer uplift.
One completely free support engineer whose previous summer purpose was moving bookings.
Before we began the work we gathered specific KPIs which we plan to improve but also put in place time to build out help guides as we do for all of our features with the Customer Success team.
We expect to see:
A 95% reduction in move requests during Summer (1st July - 31st August)
A 15% increase in availability and occupancy across all revenue generating units compared to the expected summer uplift.
One completely free support engineer whose previous summer purpose was moving bookings.
Before we began the work we gathered specific KPIs which we plan to improve but also put in place time to build out help guides as we do for all of our features with the Customer Success team.
We expect to see:
A 95% reduction in move requests during Summer (1st July - 31st August)
A 15% increase in availability and occupancy across all revenue generating units compared to the expected summer uplift.
One completely free support engineer whose previous summer purpose was moving bookings.
Work experience
Work experience
David Larpent
Chief Product Officer
Sarah is an fantastic designer and all round excellent colleague. I worked closely with Sarah for 2 years on many complex discovery and design challenges. She has a great eye for detail, prodigious intellect and impeccable work ethic. Most importantly, however, she is a total pleasure to work with. If you are lucky enough to get the chance, you should hire her at once!
Johnny Siu
Senior Product Manager & Antler Resident
Sarah’s attention to detail, combined with a deep understanding of business needs, enables her to generate creative solutions. Cutting through complex problems & design solutions that address the needs of various stakeholders. Her contributions extend beyond her role; supporting me as a PM by demonstrating strong commercial acumen and proposing viable solutions. She works closely with our engineers acknowledging technical constraints while pushing for a better user experience. I would wholeheartedly recommend Sarah for any design role. She is not only a talented designer but also a great person & joy to have on any team.