We pulled every chat message mentioning "points" over a two-month stretch of support logs, close to 7,600 messages in all. Reading through them wasn't like triaging a pile of unrelated questions. The same handful of confusions kept resurfacing, worded differently each time, but structurally identical. That kind of repetition is usually a sign the problem isn't in the rules themselves. It's in the gap between how the system was built and how people actually think.
A membership points system can be internally consistent, every rule making sense in isolation, and still generate constant confusion, because the system and the member are answering different questions with the same word: points.
What the system is actually tracking
On the system side, points aren't one thing. They're several categories, each governed by its own rules: eligibility rules for different point types, saving and borrowing mechanics that move points between years, conversion rules for exchanging points into partner programs, fees attached to specific transactions, and inventory rules that tie a booking to a specific funding year rather than the calendar year most people plan around. Every one of those rules exists for a real operational reason. None of them is unreasonable on its own.
What the member is actually asking
Ask a member what they're trying to figure out, and the questions look nothing like the system's categories. Do I have enough for this trip? Which year's points am I actually spending? Is this a good use of my points compared to my other options? What happens to my points if I have to cancel? What's left for my next trip if I use these now?
None of those questions care which bucket a point came from. They treat points the way people treat a single currency: fungible, cumulative, spendable.
Where the two stop agreeing
Lay the two layers side by side and the friction stops being abstract.
| The system | The member | What it produces |
|---|---|---|
| Points exist in multiple, rule-bound buckets | Points are one unified balance | Confusion over why points aren't "available" for a booking |
| Rules run on a fixed check-in or funding year | Planning runs on the calendar year | Missed deadlines for saving or borrowing points |
| Fees are separate transactional events | Fees are part of the total trip cost | Sticker shock late in the booking flow |
None of these are edge cases. They're the default experience of anyone trying to plan a trip with points, because the system's organizing logic and the member's organizing logic were never actually the same logic to begin with.
What this is and isn't
Worth naming plainly: this is a read of support conversations, not a controlled study. It tells you where people got stuck enough to ask for help, not how everyone experiences the system, including the people who never had to ask. It also doesn't prove which fix works, only where to aim one. Testing whether members' stated priorities hold up against the system's actual constraints is a different piece of work, and a necessary next step before building anything.
What I'd carry forward
A few things this kind of analysis is good for on any system with a similar shape, one currency built out of several rule-bound sources that people want to think about as a single number:
Read support logs for structural repetition, not just topic frequency. The same underlying confusion often shows up worded a dozen different ways.
Write the system's mental model and the user's mental model down as two separate lists before trying to fix anything. The friction is usually visible the moment they sit side by side.
Look for places where the system's unit of time, a fiscal year, a billing cycle, a funding year, doesn't match the unit of time people actually plan around.
Treat "is this a good use of my balance" as a real question the interface needs to answer, not a nice-to-have. It showed up on its own, without being asked for.
"The system wasn't wrong, and neither were the members. They were running two different models of the same thing, and nobody had put both models on paper long enough to see exactly where they diverged."
Closing
That's a cheaper problem to find than to guess at, and cheaper still than shipping a fix for the wrong one.