A comparison table is not a decision.

Why doesn't the big comparison table work?

Because it answers a question nobody asked. You've seen the page: three or four options across the top, forty rows down the side, and a field of checkmarks. Most rows are checked for everybody. The few that aren't are phrased in the product's language, not the buyer's.

So people do the sensible thing. They scroll to the price row, pick the middle option, and hope. Or they call your sales team and ask the question the table was supposed to answer: "Which one is right for me?"

That phone call is the clue. For a simple product, a table is fine. For anything where the right choice depends on the buyer's circumstances, such as insurance plans, financing options, software tiers, service packages, or equipment, the table moves the hard part of the decision onto the person least equipped to do it.

What should a comparison tool ask first?

Something about the person, not the product. Two to five questions, chosen because each one actually narrows the field or changes what matters.

Good first questions are about situation and constraints: what they're trying to do, what's fixed for them, what they can't live without. "How many people will use this?" "Do you already have a doctor you need to keep?" "Will this be used outdoors?" If an answer wouldn't change which options you show or how you explain them, cut the question. Every extra question costs you people who leave.

Then use the answers. Hide the options that clearly don't fit, with a short note saying why, so nobody thinks you're hiding something. Reorder what's left by fit, not by margin. If you have a commercial reason to favor one option, be careful: people can tell, and a tool that steers loses trust faster than a plain table.

Which differences deserve a row?

Only the ones that change the outcome for this person. That's a much shorter list than the feature grid, and it changes depending on their answers.

The trick is to translate each difference into a consequence they can picture. "Deductible: $1,500 vs $3,000" is a fact. "If you see a specialist a few times this year, you'd likely pay more out of pocket with the second plan" is something a person can weigh. You're not making the choice for them. You're doing the arithmetic they would have done if they had the time and the background.

This is harder than it sounds, because it means the tool has to understand the product well enough to explain it. Usually that understanding lives with your best salespeople or account managers. Spend time with them first. Ask how they explain the difference on a call. Those explanations are the content of your tool.

You might be wondering whether a chat assistant could do this instead: let people type their situation and get an answer. Sometimes it can help, especially for gathering the situation in the buyer's own words. But the hard part doesn't go away. The assistant still needs the same carefully kept product data, the same rules about which differences matter, and the same honesty about assumptions. Without those, it will produce a fluent answer that nobody on your team can stand behind. Build the reasoning first. A conversational front end can sit on top of it later if people actually want one.

How do you keep it honest?

Show your working. Every consequence you describe rests on assumptions: a typical usage pattern, current prices, a rule that might change next year. Say what they are, near where they're used, in plain words.

Show how fresh the data is. Plans, prices, and terms change. If the tool is reading from data that was updated last quarter, say so, and make it someone's job to keep it current. A comparison tool with stale data is worse than none, because it looks authoritative.

Say what you don't know. If a buyer's situation falls outside what the tool can reason about, tell them and offer a person. "This depends on details we can't check here. Talk to someone" is a perfectly good answer.

And keep the fine print reachable. The simplified view is for choosing. Anyone who wants the full terms should be one click away from them.

Before launch, test it against cases your team remembers. Ask your salespeople for the buyers who chose wrong, or nearly did: the family that picked the cheap plan and then had a year of appointments, the customer who bought the small tier and outgrew it in a month. Run those situations through the tool. If it would have pointed them the same wrong way, you've found a missing question or a missing consequence. Fix it before a real buyer finds it for you.

What did Wellthie teach us?

That this is as much a communication problem as an engineering one. On Wellthie, we helped process complex healthcare data and turn it into experiences that gave consumers and businesses the context to review their options and decide. The engineering mattered: the data was complicated and had to be handled carefully. But the harder part was preserving the distinctions that actually matter, making the choices understandable, and helping people see what the information meant for them.

Healthcare is an extreme case, but the shape repeats. Whenever the options are genuinely complex, the value isn't in showing everything. It's in showing the right thing to the right person and being clear about what's behind it.

Where should we start?

With your current comparison page and three real questions from customers. Pull them from sales calls, support tickets, or chat logs: the questions people asked because the page didn't answer them. Then sit with whoever answers those questions best and record how they explain the choice.

From there, a first version can be small: a few situation questions, a filtered set of options, and three or four consequences written in plain language, with assumptions visible. Put it in front of real buyers, watch where they hesitate, and improve it with the people who answer the phone.

That's the kind of web application work we enjoy most, where the software has to understand the business well enough to explain it. If your customers keep calling to ask which option is right for them, show us the page they were looking at.