Guest recovery
Guest recovery
Designed the end-to-end guest disruption resolution flow across four brands, mobile and web; consolidating what was scoped as three separate flows into one adaptive system that responds to the severity of the disruption.
Designed the end-to-end guest disruption resolution flow across four brands, mobile and web; consolidating what was scoped as three separate flows into one adaptive system that responds to the severity of the disruption.
COMPANY
AWAZE (4 BRANDS)
ROLE
PRODUCT DESIGN
PLATFORM
Web & native app
The Challenge
The Challenge
When a guest's property becomes unavailable, the business faces its highest-stakes moment in the guest relationship. Awaze had no self-serve resolution path — every disruption was handled manually by customer service, creating operational cost, delay, and a trust deficit at the worst possible time. The absence of a structured flow meant every case was an exception, and every exception was expensive.
When a guest's property becomes unavailable, the business faces its highest-stakes moment in the guest relationship. Awaze had no self-serve resolution path — every disruption was handled manually by customer service, creating operational cost, delay, and a trust deficit at the worst possible time. The absence of a structured flow meant every case was an exception, and every exception was expensive.
When a guest's property becomes unavailable, the business faces its highest-stakes moment in the guest relationship. Awaze had no self-serve resolution path — every disruption was handled manually by customer service, creating operational cost, delay, and a trust deficit at the worst possible time. The absence of a structured flow meant every case was an exception, and every exception was expensive.
My Contribution
My Contribution
Took a brief scoped as three separate flows and redesigned it as a single adaptive system, hiding options contextually based on disruption type, so guests are never exposed to complexity that doesn't apply to them. Introduced an interactive map displaying available relocation properties with calculated distances, giving guests the spatial context to make an informed choice. Designed the full payment architecture for credit application and cost-difference handling, and defined new entry points through revised email and app inbox — advocating separately for the inbox feature as a prerequisite for the flow to work end-to-end.
Early prototypes and testing shaped the business's own thinking, steering focus toward the right strategic questions: how many properties to offer, how to prioritise guest needs, and where the resolution experience should begin.
Took a brief scoped as three separate flows and redesigned it as a single adaptive system, hiding options contextually based on disruption type, so guests are never exposed to complexity that doesn't apply to them. Introduced an interactive map displaying available relocation properties with calculated distances, giving guests the spatial context to make an informed choice. Designed the full payment architecture for credit application and cost-difference handling, and defined new entry points through revised email and app inbox — advocating separately for the inbox feature as a prerequisite for the flow to work end-to-end.
Early prototypes and testing shaped the business's own thinking, steering focus toward the right strategic questions: how many properties to offer, how to prioritise guest needs, and where the resolution experience should begin.
Took a brief scoped as three separate flows and redesigned it as a single adaptive system, hiding options contextually based on disruption type, so guests are never exposed to complexity that doesn't apply to them. Introduced an interactive map displaying available relocation properties with calculated distances, giving guests the spatial context to make an informed choice. Designed the full payment architecture for credit application and cost-difference handling, and defined new entry points through revised email and app inbox — advocating separately for the inbox feature as a prerequisite for the flow to work end-to-end.
Early prototypes and testing shaped the business's own thinking, steering focus toward the right strategic questions: how many properties to offer, how to prioritise guest needs, and where the resolution experience should begin.
The brief proposed 3 flows.
I solved with 1.
Self-serve resolution
Single adaptive flow
Interactive map & inbox
“Marisa has leveraged high quality research to solve incredibly complex problems resulting in designs that feel simple and intuitive. Absolutely stellar work.”
Martin R.
Head of Product
Password required
Enter the password to unlock the in-depth examination of the problem, ideas, solutions, and challenges.
( THE PROBLEM )
Initial Data
Initial Data
The high volume of customer support contacts for post-book related issues pushed the business to create a company wide initiative to turn investigate the reasons behind these calls.
Post-Book
33%
contacts related to the pre-arrival experience
BILLING
18%
contacts related to payments, invoices and additional costs
EXTRAS
6%
contacts related to adding, removing, paying and locating
POST-BOOK
33%
contacts related to the pre-arrival experience
BILLING
18%
contacts related to payments, invoices and additional costs
EXTRAS
6%
contacts related to adding, removing, paying and locating
( ASSESSMENT)
The Diagnostic
70%
of all payments are made post-booking
yet the current experience was the biggest source of revenue leakage in the business.
Comprehension
Areas of inquiry
Routing was unclear across the system: where emails, notifications, bills, and payments actually surfaced — or failed to — was not consistently understood. It was not yet known whether this stemmed from the page's structure, the underlying data, or both.
Information architecture
Cost structure
BDP & emails
Payments
( STRUCTURAL INVESTIGATION )
Identifying Core Issues
Conflicting priorities, structural issues and backend dependencies needed further exploration to understand how to make design improvements.
01 / Journey alignment
01 / Journey alignment
02 / Occurences
02 / Occurences
03 / Extras
03 / Extras
04 / Scenarios
04 / Scenarios
NAMING CONVENTIONS
No ubiquitous language across dev and design for costs that do not fall into instalments
PAYMENT SCHEDULE
Costs can occur pre-arrival, on arrival, and post stay. Types include Mandatory Extras, Optional Extras,as well as additional 3rd party costs ex. Tourist Tax
COST DISPLAY
Variable mandatory costs such as electricity have multiple cost tiers ex. fixed rate for week 36-37, then per usage rate week 38-40
01 / Journey alignment
01 / Journey alignment
02 / Occurences
02 / Occurences
03 / Extras
03 / Extras
04 / Scenarios
04 / Scenarios
NAMING CONVENTIONS
No ubiquitous language across dev and design for costs that do not fall into instalments
PAYMENT SCHEDULE
Costs can occur pre-arrival, on arrival, and post stay. Types include Mandatory Extras, Optional Extras,as well as additional 3rd party costs ex. Tourist Tax
COST DISPLAY
Variable mandatory costs such as electricity have multiple cost tiers ex. fixed rate for week 36-37, then per usage rate week 38-40
( DEPENDENCIES )
Ongoing cross-team discussions
Discussing problem areas that result in financial loss and have longterm positive impact if addressed.
Owner team
Pricing consolidation
Simplified pets
Apex team
Backend dependencies
Legacy to AGE migration
3rd parties
Booking payments
Relocations
( ACTION PLAN )
Vision for Target Areas
(04)
How we get paid
Digital payments only: remove cash payments on arrival.
(02)
How we communicate
Clear naming conventions for extra costs and better content organization.
(04)
How we get paid
Digital payments only: remove cash payments on arrival.
(02)
How we communicate
Clear naming conventions for extra costs and better content organization.
(04)
How we get paid
Digital payments only: remove cash payments on arrival.
(03)
Prototyping & Testing
Creating interactive prototypes to test ideas and refine usability through real feedback.
(01)
How we structure costs
Extras as add-ons: mandatory extras are not extras, they are included costs billed together.
(03)
How we bill
A single, standardized digital bill: merge mandatory extras into included costs.
(02)
Concept Development
Shaping ideas into concepts, structuring flows and features around real user goals.
TEAMS BEHIND THE WORK
Payments
Resman
APEX
AS400
Owner
Checkout
Product
Design
( USER TESTS )
Validating Ideas
Synthesizing potential blockers, business goals and UX solutions
Overview
Terminology
Timeline
Scenarios
( USER TESTS )
Validating Ideas
Synthesizing potential blockers, business goals and UX solutions
Overview
Terminology
Timeline
Scenarios
( FINDING THE BALANCE )
How much do we show?
( DEVELOPMENT )
Constraints shaping UX
What was blocked, what had to ship first, what evidence was incomplete, and how I protected the user experience anyway.
Cost structure
Backend Data Integration
Fallback copy and payment labels
Estimated consumption costs remain unavailable for a significant proportion of properties — pulling from multiple data lines that cannot be reconciled in real time.
This prevents full cost transparency on the BDP and forces a "TBD" or "based on usage" fallback for affected properties — a known trust risk that was documented and escalated, but deprioritised against higher-urgency engineering work.
Cost structure
Backend Data Integration
Fallback copy and payment labels
Estimated consumption costs remain unavailable for a significant proportion of properties — pulling from multiple data lines that cannot be reconciled in real time.
This prevents full cost transparency on the BDP and forces a "TBD" or "based on usage" fallback for affected properties — a known trust risk that was documented and escalated, but deprioritised against higher-urgency engineering work.
Cost structure
Backend Data Integration
Fallback copy and payment labels
Estimated consumption costs remain unavailable for a significant proportion of properties — pulling from multiple data lines that cannot be reconciled in real time.
This prevents full cost transparency on the BDP and forces a "TBD" or "based on usage" fallback for affected properties — a known trust risk that was documented and escalated, but deprioritised against higher-urgency engineering work.
How we communicate
Additional Costs
Timeboxed subsections
Consumption costs cannot display a fixed amount where backend data is incomplete — the UI handles this with a "based on usage" pattern and a clear on-site payment label to set expectations before arrival.
Cash payments remain required at some properties — a constraint outside the scope of this redesign but surfaced explicitly in the UI to prevent guest confusion at arrival.
How we communicate
Additional Costs
Timeboxed subsections
Consumption costs cannot display a fixed amount where backend data is incomplete — the UI handles this with a "based on usage" pattern and a clear on-site payment label to set expectations before arrival.
Cash payments remain required at some properties — a constraint outside the scope of this redesign but surfaced explicitly in the UI to prevent guest confusion at arrival.
How we communicate
Additional Costs
Timeboxed subsections
Consumption costs cannot display a fixed amount where backend data is incomplete — the UI handles this with a "based on usage" pattern and a clear on-site payment label to set expectations before arrival.
Cash payments remain required at some properties — a constraint outside the scope of this redesign but surfaced explicitly in the UI to prevent guest confusion at arrival.
How we bill
Payment schedule
INLINE PAYMENT DRAWER, MANDATORY COSTS SURFACED
Card data cannot be retrieved or saved; payments are processed through an iFrame with no card tracking across sessions.
Individual instalment breakdowns are unavailable at line level; upcoming mandatory costs are surfaced as the nearest actionable alternative.
How we bill
Payment schedule
INLINE PAYMENT DRAWER, MANDATORY COSTS SURFACED
Card data cannot be retrieved or saved; payments are processed through an iFrame with no card tracking across sessions.
Individual instalment breakdowns are unavailable at line level; upcoming mandatory costs are surfaced as the nearest actionable alternative.
How we bill
Payment schedule
INLINE PAYMENT DRAWER, MANDATORY COSTS SURFACED
Card data cannot be retrieved or saved; payments are processed through an iFrame with no card tracking across sessions.
Individual instalment breakdowns are unavailable at line level; upcoming mandatory costs are surfaced as the nearest actionable alternative.
How we get paid
Payment scenarios
MODAL PRICE ALERT, INLINE PAYMENT OR CLEAR LEGACY REDIRECT
Booking changes made in the edit flow cannot be paid inline; users are alerted to the price difference via modal, with local payment offered where possible and a clear legacy redirect where not.
Credit agency bookers cannot currently pay for extras on site; a payments team initiative to enable card saving and tracking is in progress.
How we get paid
Payment scenarios
MODAL PRICE ALERT, INLINE PAYMENT OR CLEAR LEGACY REDIRECT
Booking changes made in the edit flow cannot be paid inline; users are alerted to the price difference via modal, with local payment offered where possible and a clear legacy redirect where not.
Credit agency bookers cannot currently pay for extras on site; a payments team initiative to enable card saving and tracking is in progress.
How we get paid
Payment scenarios
MODAL PRICE ALERT, INLINE PAYMENT OR CLEAR LEGACY REDIRECT
Booking changes made in the edit flow cannot be paid inline; users are alerted to the price difference via modal, with local payment offered where possible and a clear legacy redirect where not.
Credit agency bookers cannot currently pay for extras on site; a payments team initiative to enable card saving and tracking is in progress.
( TRADEOFFS & WINS )
What shipped
( TAP: BEFORE/AFTER )
( NEXT STEPS )
Future Thinking
( REFLECTIONS )
Learnings
How I found a way to execute despite roadblocks and obstacles.
01 — SYSTEMIC GAPS ARE DESIGN OPPORTUNITIES
Where no established foundation exists, there is room to define one. Identifying areas of ambiguity and structural weakness early — rather than working around them — creates the conditions for disproportionate impact. The absence of prior investment is not a blocker; it is leverage.
02 — CLARITY COMPOUNDS
03 — EVIDENCE MOVES ORGANISATIONS
04 — DESIGN FOR FAILURE STATES FIRST
© 2026 - Marisa Eva