Purchase Protection
How user research steered the payments team away from rebuilding a feature that had already failed once.
Company
Checkfront
Team
Product Manager, Engineers, Customer-facing teams
Role
Product Designer
Methods
User interviews, research synthesis, stakeholder alignment
Year
2023
Timeline
3 weeks
IMPACT AT A GLANCE
Team realigned on real problem
Focus moved from implementation to vendor selection, backed by evidence.
Months of rework avoided
The team skipped months of building a feature that would have failed the same way.
A second failed launch prevented
Checkfront avoided shipping the same broken experience to operators a second time.
OVERVIEW
A feature that failed once, up for a second chance
Checkfront offers a flexible online booking system that helps operators run complex booking operations.
Purchase Protection was a booking insurance add-on. Operators could enable it so their customers could add insurance to a booking for an additional fee. This protected guests in case of an emergency and gave operators a new revenue stream.
Checkfront first offered Purchase Protection through an insurance vendor in 2020. The feature was sunset and pulled from new operators because of poor reception. In 2023, the payments team wanted to revive it.
Launched with a third-party insurance vendor
Operators could let guests add booking insurance for a fee, creating a new revenue stream.
SUNSET
Sunset after poor reception
The feature failed to land with operators and Checkfront discontinued it.
The payments team sets out to bring it back
A second attempt begins, this time starting with research into why it failed the first time.
The team was about to solve the wrong problem
The instinct was to treat this as an implementation problem: how do we build Purchase Protection better into Checkfront this time? That framing rested on two things no one had checked.
Do operators actually want this feature?
The 2020 version failed, but no one had confirmed whether the demand was real or the execution was the issue.
Is the problem even inside Checkfront's product?
If the real failure was somewhere else, rebuilding the same feature would repeat the same mistake and cost the team months.
Three questions the research had to answer
I was tasked with leading discovery research to answer the following three questions:
#1
Is the appetite real?
Confirm whether operators currently want to offer Purchase Protection in their businesses.
#2
Why did it fail in 2020?
Surface the root cause from both the operator side and the internal team side.
#3
What does "better" mean?
Give the payments team an evidence-based problem statement so they could invest in the right solution.
DISCOVERY
Problems learned from the 2020 docs
Because this feature already existed, I started with a review of the 2020 documentation to gather early signals before talking to anyone. These findings helped shape the questions I brought into the interviews.
No control over protected bookings for operators
Operators couldn't cancel protected bookings inside Checkfront. Their only option was to send guests to the vendor to file a refund claim, then wait 1 to 2 business days for it to clear before reselling the spot.
No self-serve claims for guests
Guests had to call the vendor to file a claim, since there was no self-serve option online. When a policy covered multiple attendees, each one had to repeat the process individually.
Interviews recorded and tagged in Dovetail so each insight traced back to a source quote.
Customer interviews
Do operators actually want this?
I interviewed operators across two groups to separate demand from execution. Every session was recorded and tagged in Dovetail so insights could be traced back to source quotes during synthesis.
Past users
Operators who used Purchase Protection in 2020, to understand their pain points firsthand.
Never-used operators
Operators who never adopted it, to gauge genuine interest today.
Internal interviews
Why did it fail the first time?
Demand alone didn't explain the 2020 failure. To find the root cause, I interviewed two internal groups.
Customer-facing teams
Customer support and sales, to find the common themes in operator complaints.
Engineering teams
To understand the technical pain points from implementing the feature into Checkfront.
INSIGHTS
What the research uncovered
Five insights emerged across the operator and internal interviews. Together they moved the team's understanding from "how do we build this" to "what actually broke last time."
Cancellations and reschedules cause real, recurring financial loss
Most operators lose money when guests cancel or reschedule, because they are unlikely to resell those spots. On top of that, they absorb non-refundable Stripe fees, credit card fees, and chargebacks.
"That's a big chunk of our daily income that people are asking us to refund at short notice."
Operator, activity business
Operators want automation and a seamless customer experience
Operators highly value business automation and a smooth experience for their guests. A clunky, off-platform flow is a dealbreaker.
"Everything in one platform, one basket. That's how I'd rather present it to our customers."
Operator, tour business
Operators are split on embedded vs opt-in
Some operators want protection embedded into every booking for a seamless experience. Others want an opt-in checkbox to match their industry standard.
"I imagine it as a checkbox at checkout. Spend a bit extra to protect my booking."
Operator, activity business
The 2020 feature broke Checkfront's core flexibility
Because the policy was tied to a booking's price, any booking edit could invalidate it. Renewing policies and claiming refunds was complex and clashed with Checkfront's flexible product.
"Once you've made an edit, it was difficult, sometimes impossible, to undo."
Internal team, customer support
The vendor, not the platform, was the bottleneck
Customer-facing teams struggled to support operators because of the vendor's poor documentation and thin support. Engineering pointed to unclear docs, slow and unstable APIs, and low response times.
"When COVID hit, the vendor refused to refund anyone. That's literally the reason you'd get insurance."
Internal team, customer support
"Their test environment for creating policies went down about 20% of the time."
Internal team, engineering
The questions these insights raised
Synthesis turned the insights into a short set of How Might We questions that reframed the work:
SYNTHESIS
The evidence pointed somewhere the team didn't expect
I documented the findings and presented them to the payments team, then shared them with the customer-facing teams so everyone understood the same root cause. The research pointed to one conclusion.
The 2020 feature didn't fail because Checkfront built it poorly. It failed because the vendor couldn't support Checkfront's flexibility or give guests a self-serve way to claim refunds.
The instinct
How do we implement Purchase Protection better inside Checkfront?
Assumes the problems lives in the product.
The real problem
How do we choose a vendor whose policy support our booking edits and gives guests self-serve claims?
Targets the root cause the research uncovered.
Turning the insight into vendor criteria
The reframe gave the payments team two non-negotiable criteria to evaluate any vendor against, both drawn straight from the 2020 failure.
By 2023, the previous vendor had added self-serve claim submission, which solved one of the two problems. But their claims process still couldn't support Checkfront's booking edits. This confirmed the team needed a different vendor rather than a second attempt with the same one.
#1
The vendor's policy has to keep up with how fast and flexibly Checkfront operators edit bookings.
#2
Guests need a self-serve way to submit and process refund claims.
IMPACT
What the research changed
By reframing the problem before any build began, the research changed where the team spent its energy.
Team realigned on real problem
Focus moved from implementation to vendor selection, backed by evidence.
Months of rework avoided
The team skipped months of building a feature that would have failed the same way.
A second failed launch prevented
Checkfront avoided shipping the same broken experience to operators a second time.
TAKEAWAY
What I learned
#1
Problem validation before the solution
The team was ready to build. Asking whether we were solving the right problem at all was the highest-leverage move on the project.
#2
Triangulate across sources
Pairing the 2020 docs with operator and internal interviews let me separate demand from execution and pinpoint the real root cause.
#3
Shared research changes decisions
Presenting to the payments team and the customer-facing teams put everyone on the same root cause, which made the change in direction easy to align on.
Next project
