Postbook Billing
Postbook Billing
Redesigning the billing architecture, cost structure, and payment communication across four holiday rental brands, on web and native app.
Redesigning the billing architecture, cost structure, and payment communication across four holiday rental brands, on web and native app.
COMPANY
AWAZE (4 BRANDS)
ROLE
PRODUCT DESIGN
PLATFORM
Web & native app
The Challenge
The Challenge
Awaze operates four holiday rental brands across Europe and the UK, each built on separate legacy systems acquired over time, never fully unified. The post-booking experience inherited that fragmentation: inconsistent billing logic, unclear cost communication, and a payment architecture that guests couldn't navigate without calling support.
The business cost was measurable. 57% of all post-booking support contacts were billing and payment related- a direct drain on revenue recovery, customer confidence, and operational cost.
This was not a content problem; it was systemic.
Awaze operates four holiday rental brands across Europe and the UK, each built on separate legacy systems acquired over time, never fully unified. The post-booking experience inherited that fragmentation: inconsistent billing logic, unclear cost communication, and a payment architecture that guests couldn't navigate without calling support.
The business cost was measurable. 57% of all post-booking support contacts were billing and payment related- a direct drain on revenue recovery, customer confidence, and operational cost.
This was not a content problem; it was systemic.
Awaze operates four holiday rental brands across Europe and the UK, each built on separate legacy systems acquired over time, never fully unified. The post-booking experience inherited that fragmentation: inconsistent billing logic, unclear cost communication, and a payment architecture that guests couldn't navigate without calling support.
The business cost was measurable. 57% of all post-booking support contacts were billing and payment related- a direct drain on revenue recovery, customer confidence, and operational cost.
This was not a content problem; it was systemic.
My Contribution
My Contribution
Identified systemic gaps, built the business case, and drove the redesign end-to-end across four legacy brands, from architecture to shipped UI, on web and native app.
Identified systemic gaps, built the business case, and drove the redesign end-to-end across four legacy brands, from architecture to shipped UI, on web and native app.
Identified systemic gaps, built the business case, and drove the redesign end-to-end across four legacy brands, from architecture to shipped UI, on web and native app.
98%
payment success rate
-42%
customer support calls
+24%
extras ordered online
10+
positively impacted teams
11
design awards & recognitions
Decades of complexity.
Simplified with design.
Unified billing architecture
Mandatory costs included
Cash payments eliminated
Consistent cross-platform UI
“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.
(03)
Prototyping & Testing
Creating interactive prototypes to test ideas and refine usability through real feedback.
(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.
(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