When something is free, people assume there's nothing left to do to claim it. That's usually right, which is what makes it a problem in this project. Eligible users were being handed a free flight reschedule, and a share of them never finished claiming it, because "free" had already closed the loop in their heads. The request sat there until it expired. The fix wasn't to nudge them harder on the last step, but to question whether the step needed a person at all.
The situation
Reschedule has a life after you submit it. The request gets processed, and depending on the case, the user has a part to play before a new e-ticket can exist.
For involuntary flight changes, the kind triggered by an airline-side schedule change, eligible users often get the reschedule free of charge. Even then, the old flow had them complete a confirmation step so the new ticket could be issued. A free request still needed a final yes.
Those free requests were expiring at a rate nobody liked. Not because people had decided against the reschedule (they'd asked for it). They just stopped at the point where the cost dropped to zero, on the reasonable read that a free thing handed to you doesn't come with homework. The request had an expiry window, and a chunk of users were spending it doing nothing, because nothing felt like the correct response to good news.
I came onto this as Design PIC, working from the research through the concept and the copy.
The approach
When the problem is "users missed a step," there were two ways to close that gap. Take the step away when nothing about it actually needed a human, and where a human did have to act, make the action so plain it couldn't be mistaken for optional. Both of those were copy decisions before they were anything else.
The work here wasn't convincing anyone to take a free reschedule. They'd already asked for it. It was getting out of the way of the one they'd been promised, and making sure that when the way couldn't be cleared, the last step at least stopped hiding behind a word.
Artifacts
The impact
01
Within about a month of release, the share of free reschedule requests that expired dropped from 25% to 15%.
02
Of all eligible involuntary requests, 36% opted into auto-issuance, and 94% of those did it through self-service rather than going to an agent.
03
Repetitive reschedules, the same booking cycling through the flow more than once, fell from 18% to 15%, roughly 60 bookings a week that stopped bouncing back.
04
Nothing came back in complaints or DSAT about the feature, which is a small signal that the change read as clear.
WHAT DIDN'T WORK
A sliver of opted-in, confirmed-free requests still expired. The completion logic leaned on an internal free-status flag being set right, and now and then it wasn't, so the system never registered the green light it had been given. The fix in flight keys completion off the actual amount owed, which for these is zero, instead of trusting the flag to be flipped. The instinct to automate was sound. The dependency it was resting on wasn't quite as reliable as the automation needed it to be.
WHAT THIS UNLOCKED
The thing I kept from this one is that "ask the user" vs "act for the user" is a content call as much as an engineering call. Whether a screen carries a button or carries a result, whether a status describes the system or names a task, that's all words deciding what the product does, not just how it sounds doing it. I'd come into reschedule expecting to write the strings on top of a flow someone else shaped, but this was the one where the strings and the flow turned out to be the same decision.