INTERNAL SAAS · MULTI-STAKEHOLDER WORKFLOW
A concept redesign of a fragmented damage-claims process at a national vacation rental operator — told the way the problem actually moves: one claim, passing through three teams, going dark at every handoff.
ROLE
Product Designer (solo)
CONTEXT
Concept redesign of a claims workflow backed by triaged data over four years
STAKEHOLDERS
Housekeeping · Operations Managers · Administrative Claims
BACKGROUND
Hundreds of claims a day, no shared system
A nationwide property management operation processed hundreds of damage claims a day across three teams, with no system connecting them — housekeeping filing manually, managers tracking cases across disconnected queues, admin coordinating over Excel, SMS, and phone. Every unresolved claim held a unit out of guest-ready condition and left recoverable costs on the operator's books.
3×
monthly claim volume from Jan 2022, against flat headcount and process
16%
of resolved claims closed for missing evidence — never submitted, never recoverable
$413K
in damage cost across five years with with no record of recovery
THE PROBLEM
The process didn't change when the volume tripled
Submissions ran 30–90 a month through 2021, then jumped to 150–240 from January 2022 and stayed there. Median filing time doubled over the same period, from 2–4 days to 5–7, and never came back down.
The claims that failed took longest to file: a mean of 12.6 days for those closed as missing cost or photos. Slow filing meant thin evidence, and thin evidence meant the claim was never submitted at all. Behind that sat a wider gap — five years of claims with no outcome recorded, a process failure that cost real recoverable dollars.
How might three teams with competing workflows share ownership of a single claim — from the moment damage is found to the moment it's paid?
THE OPPORTUNITY
One platform, three workflows
Redesign the end-to-end claims process so three teams with competing workflows operate from one structured system that closes the gaps between them — and gets units back to guest-ready condition faster.
RESEARCH
Every failure lived at a handoff
Lived experience pointed to where the pain was — it couldn't confirm whether that pain was universal. So the assumptions behind it got tested like any other hypothesis: claim-queue data from 2019–2023, the end-to-end process mapped across all three teams, synthesized into a service blueprint, and interviews run with housekeepers and local operations managers — the two groups furthest from the resolution and closest to the damage.
Service blueprint of the claims process as it ran — three teams, three phases, and the points where a claim lost the evidence it needed.
Field delays compounded downstream
Housekeeping had no structured way to attach photos or descriptions at the point of discovery. Five days on average from damage found to ticket created; two more before guest contact.
Reassignments erased accountability
Once a ticket passed between departments, its creator lost sight of it. In peak season resolutions stretched to three months — usually noticed first by an escalated homeowner.
Nobody could see where a claim stood
Status lived in comment threads, side channels, and institutional memory. New managers dug through SOPs to answer basic questions.
Every failure sat at a handoff
Three separate breakdowns, one shared location: the moment a claim passed from one team to another and briefly belonged to no one.
DESIGN PRINCIPLES
Three failures, three rules
Each finding became a rule I could hold every design decision against.
CAPTURE AT THE SOURCE
Structure the data at the moment of discovery — not through corrections later.
TRIAGE AT A GLANCE
Urgency should be visible without opening a single ticket.
ONE SOURCE OF TRUTH
If the answer lives in a side channel, the system has already failed.
Three principles, three teams. Here's what changed at each point the claim passes through — and what each change was worth downstream.
HOUSEKEEPING
The heaviest burden, the least support
Problem
Housekeepers — first on the scene, working under time pressure, often the least experienced with internal tooling — faced the most complex submission flow in the entire process. Incomplete tickets at the origin triggered a chain of corrections that slowed every stage after.
There's no good way to take photos. I'm not sure what to take photos of. I'm not 100% comfortable with technology. The ticketing system is cumbersome, and I don't know who to assign it to.
Composite of housekeeper interviews
The design
Guided by capture at the source, submission became a short sequence of single-task steps with the structure built in. Photo capture replaces “attach photos” with a named shot list — context, full view, close-up — each with what it's for and a live capture status, and an explicit way to mark a shot unavailable so a gap gets justified rather than silently skipped. Assignment leaves the housekeeper's hands entirely: tickets route to the unit's local manager.
Submission stages, drawn to the same scale. Over half the reduction came from deriving disposition and capturing photos in flow.
Fields
BEFORE
Unit, severity, disposition and assignee were each asked as separate dropdowns. Disposition alone was three dependent menus — 12 steps.
AFTER
Unit and reservation pre-fill from the ticket. Disposition is derived from the issue type rather than asked. Assignment routes to the unit's local manager.
Evidence
BEFORE
"Attach" opened the phone's file picker — 4 to 10 steps per file, with no guidance on what to photograph.
AFTER
A named shot list captured in flow: context, full view, close-up, each with what it's for and a live capture status.
Requirements
BEFORE
The form did list what a claim required — reservation number, photographs, description, cause, reporter — as static boilerplate in a text box, above a submit button the reporter couldn't see while reading it.
AFTER
The same requirements become a checkable flow: each one captured as its own step, with completeness confirmed on screen before the ticket can be submitted.
The same three moments in the flow, before and after.
Why it works
The step count dropped from 47 to 21, but the real gain is what arrives downstream. Claims closed for missing cost or photos took 12.6 days to file against a 6 day baseline — the slowest claims were the least documented. Capturing structured evidence at the moment of discovery removes both problems at once.
Structured data at the source only matters if someone acts on it. Downstream, operations managers were drowning in exactly this input — with no way to tell which claims couldn't wait.
OPERATIONS MANAGERS
Everything looked equally urgent
Interviews and workflow observations showed Local Operations Managers navigating a high-volume, fragmented ticketing experience that made it difficult to understand priorities, find relevant information, and take action efficiently.
Emerging problem themes
01 High cognitive load
“It’s hard to track everything, and sometimes I can’t find the ticket.”
Managers were juggling large volumes of tickets with limited visibility into what needed attention first.
02 Unclear ownership
“I’m not always sure who to assign it to—or what I’m missing.”
Managers lacked confidence around who should own a ticket and whether they had enough information to hand it off.
03 Fragmented workflows
"Different listing sites become very nuanced in their processes."
Different listing platforms and operational processes introduced inconsistencies and additional complexity.
04 Limited mobile usability
“There’s too much to manage, and the process isn’t intuitive.”
Existing workflows were difficult to navigate and act on effectively while working away from a desktop.
From interviews and day-to-day work with local operations managers
PRIOR Manager workflow screens
Scroll to explore
Desktop · MAINTENANCE ticket queue
Mobile · DAMAGE ticket VIEW and PROCESSING
The design
Guided by triage at a glance, claims stay inside the ticket list managers already work from - marked by type rather than moved into a separate tool. Inside a claim, readiness leads: whatever is missing is named alongside the action that clears it, so the manager becomes the checkpoint that catches incomplete evidence before it reaches admin.
Why it works
It matches how managers actually work: they triage a whole workload, not a claims-only queue. Urgency groups the list, the deadline is the only thing colored red, and the ticket itself says what's blocking it. That turns the manager into the checkpoint that catches missing evidence before a claim reaches admin - which is where recoverable claims were being lost.
HEARD
Ranking the queue was possible, but it took interpretation - claims looked like every other ticket until opened.
Claims live in the list managers already use.
DESIGNED
Tickets group by urgency, sort by due date, and filter by type. Claims now carry a dedicated tag for quick identification.
HEARD
Whether a ticket held enough to act on was a manual check, and assignment was a judgment call made without context.
The ticket states what's missing.
DESIGNED
Readiness leads the screen - photos, description, cost - with anything incomplete named alongside the reason it blocks and one action to clear it. Once complete, automatically gets reviewed with claims visibility.
HEARD
Each booking channel carried its own filing rules, and managers held them from memory while the clock ran.
Channel rules built into the ticket.
DESIGNED
The booking channel sets the filing window, stated plainly beside a live countdown, with protection-plan status sitting next to it.
HEARD
A claim's history was spread across comments, texts and spreadsheets - which is how tickets went missing in plain sight.
One record, not four side channels.
DESIGNED
Notes and system events share a single timeline, newest first, visible to every manager and to the claims team.
Triage tells you what's urgent - it doesn't resolve anything. That burden landed on the admin team, who coordinated every resolution with the least infrastructure of all.
ADMINISTRATIVE CLAIMS
Tracked in a spreadsheet, cross-referenced by hand
Problem
Admin sat at the most complex intersection of the process — field reports, maintenance records, reservation data, and guest communication. A spreadsheet tracked every claim, but it held none of those sources: each case meant cross-referencing several systems by hand, and a mistyped reservation or a missed update carried straight through to the filing.
The design
Guided by one source of truth, the claim arrives assembled — reservation, unit, coverage and the field team's photos populate from upstream instead of being looked up, so the cross-referencing disappears. Every damaged item carries its own evidence state, and the claim can't be submitted while any are outstanding. Allocation is explicit: platform payout, damage waiver, APP coverage, guest repayment, owner billing, each line accountable to a total.
Why it works
When the record lives in the system rather than in a sheet someone has to keep current, a dispute is settled by what was logged — not by whoever updated it last.
Anatomy of a claim
Documentation can be waived, but never silently.
A claim went quiet the same way whether the paperwork was missing or the ticket itself had moved. Once a case was reassigned to a local manager, the person who opened it lost visibility — the only way to know it was still alive was to check back in, and that meant one team manually pinging another. It depended on someone remembering to, and under volume, it didn't hold. Waiving worked the same way: a requirement could be marked resolved without the flow ever asking why. The fix treats both as one failure. A waiver is logged with who, why, and when. A reassignment keeps its original owner as a follower on the claim, not someone who has to go looking for it.
01 REQUIRED
Upload is the primary path; waiving sits as a text link underneath, not a button beside it. The easier action still leaves a record of why.
02 WAIVING
A reason code alone doesn't say who decided or why. Written detail is required, because future discussions and negotiations will need to reference this.
03 WAIVED
The waiver becomes part of the claim itself — who, why, when, and what was attached — not something anyone has to remember later. Still reversible: upload replaces it.
The queue sorts on every field a coordinator searches by.
A property manager or guest calls about damage in a unit. A third-party platform references a reservation. An insurance agent quotes an external ID. Different ways to start, one place to locate exactly where a claim stands — sortable and searchable without ever opening a spreadsheet.
Filtered to active cases and sorted by submission due date. Closed claims drop off automatically.
CAPACITY
Designed for the volume that broke the old process
Submissions tripled in January 2022 and the process never changed with them. Fixing a single claim's path doesn't answer that — the team also needed to see whether they were keeping pace, and which claims were about to be lost while they worked.
Backlog trend plots opened against resolved with open backlog on the right axis — today's overdue count understates the pressure when intake keeps outrunning throughput.
Blocked on documentation is the metric that ties it together.
Volume, aging and throughput helps identify the current pace of claims. The number illustrates how many claims can't be filed at all — the same failure the housekeeper's shot list and the manager's readiness check were built to prevent.
RESULTS
What changed, by the numbers
55%
fewer submission steps (47 → 21)
45–60%
faster resolution for previously undocumented claims
20–35%
of stalled recoup exposure recovered
Step reduction is measured against the documented current-state flow. Resolution and recoup ranges are modeled from five years of claims data — 768 claims that either lacked cost/photo documentation or missed the 14/30-day recovery window — assuming the redesign prevents 20–35% of that pattern from recurring.
SCOPE
What I built, and what went pending
Parked, not abandoned — each is a real gap, set aside by this pass's constraints.
IN THIS DESIGN
Guided capture at discovery
A named shot list, structured fields, and automatic routing — the moment the claim's outcome is decided.
Manager readiness check
Catches a missing cost or photo before a claim reaches admin, closing the gap that put claims out of recovery.
Assembled claim and waiver record
Reservation, coverage and documentation arrive already populated instead of hand-assembled across four systems; gaps get waived on the record, never silently.
Capacity view
Surfaces what's blocked on documentation right now, not just how many claims are open — the number that ties the whole redesign together.
PARKED
Vendor and contractor quotes
Cost entry runs through the manager today; a third party adds back the handoffs this project removed.
Homeowner-facing status
The blueprint shows the homeowner going dark, but that's the manager's relationship to hold, not a screen to build.
Owner billing when a unit isn't enrolled
A negotiation between manager and owner — not a decision to automate.
Offline capture
Housekeepers work in low-signal units; connectivity is this flow's most fragile assumption.
REFLECTION
Designing for teams in tension
Knowing when to restart is a design skill.
This project took more iteration cycles than scoped — including returning to directions set aside earlier. The discipline wasn't pushing the design further; it was recognizing when a simpler foundation would outperform another round of refinement.
Not three tools — one system, three truths.
Housekeeping, operations, and admin didn't just have different workflows — they had competing ones. The work wasn't building three tools; it was finding one architecture that served each team without creating a tradeoff that would kill adoption in another.
Internal tools earn their keep in losses prevented.
This tool doesn't generate revenue — it stops the bleed: tickets lost in transition, 90-day cycles, homeowners losing confidence in the operation. Framing that ROI clearly is as much the design job as the screens are.