AI triage chat
AI triage chat
Architected the end-to-end guest communication system across four brands — originating from a strategic feature recommendation within the BDP redesign and developed into a full product spanning AI triage, inbox, and account dashboard.
Architected the end-to-end guest communication system across four brands — originating from a strategic feature recommendation within the BDP redesign and developed into a full product spanning AI triage, inbox, and account dashboard.
COMPANY
AWAZE (4 BRANDS)
ROLE
PRODUCT DESIGN
PLATFORM
Web & native app
The Challenge
The Challenge
No direct communication channel existed between guests and property owners in the pre-arrival window, a systemic gap that was generating avoidable support contacts and leaving guests without the information they needed before their holiday. The business had not identified this as a priority. The feature didn't exist in any brief.
No direct communication channel existed between guests and property owners in the pre-arrival window, a systemic gap that was generating avoidable support contacts and leaving guests without the information they needed before their holiday. The business had not identified this as a priority. The feature didn't exist in any brief.
No direct communication channel existed between guests and property owners in the pre-arrival window, a systemic gap that was generating avoidable support contacts and leaving guests without the information they needed before their holiday. The business had not identified this as a priority. The feature didn't exist in any brief.
My Contribution
My Contribution
Identified the absence of pre-arrival guest-to-owner communication as an unaddressed systemic gap and originated the feature recommendation that became this product. Designed the full system end-to-end: conversational AI triage logic determining how inquiries are answered, routed, or escalated; inbox and notification architecture; and the account dashboard housing it all. The decision framework governing automated resolution and human handoff was designed to absorb routine inquiry volume while ensuring complex cases surface to the right people.
Identified the absence of pre-arrival guest-to-owner communication as an unaddressed systemic gap and originated the feature recommendation that became this product. Designed the full system end-to-end: conversational AI triage logic determining how inquiries are answered, routed, or escalated; inbox and notification architecture; and the account dashboard housing it all. The decision framework governing automated resolution and human handoff was designed to absorb routine inquiry volume while ensuring complex cases surface to the right people.
Identified the absence of pre-arrival guest-to-owner communication as an unaddressed systemic gap and originated the feature recommendation that became this product. Designed the full system end-to-end: conversational AI triage logic determining how inquiries are answered, routed, or escalated; inbox and notification architecture; and the account dashboard housing it all. The decision framework governing automated resolution and human handoff was designed to absorb routine inquiry volume while ensuring complex cases surface to the right people.
There was no brief.
I identified the gap.
Direct pre-arrival communication
AI triage and routing logic
Unified inbox/notification architecture
“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