Deciding between options

The mistake is asking which one

Which of these three CRM systems should we buy?

You will get a recommendation. It will be reasonable, it will be based on general knowledge of those products, and it will have no idea what you need, so it will weigh things by how often they matter to companies in general rather than to yours.

Decisions are made of criteria and weights, and both belong to you. What the model is good at is the part in between: gathering, structuring, and finding what you have not considered.

The sequence

1. Get the criteria out of your head.

I am choosing between three CRMs for a 14-person wholesaler. Before recommending anything, ask me what matters and what the constraints are. One question at a time.

Or, if you already know:

Criteria: monthly cost per user, works offline, imports from a spreadsheet, someone locally who can support it, exports everything if we leave. In that order of importance.

2. Ask what you have missed.

What criteria do organisations like mine usually regret ignoring in this decision?

This is where a model adds something. It has seen the shape of this decision many times; you are making it once. Data portability, contract lock-in, what happens when the person who set it up leaves: these are the ones people discover afterwards.

3. Build the comparison, with sources.

Compare the three on those criteria. One row each. Quote or link the source of every claim. Where you cannot find a figure, write “not stated”; do not estimate. Flag anything that may have changed since your training data.

4. Ask for the case against your preference.

I am leaning towards B. Give me the strongest case for A and for C, and say what would have to be true for B to be the wrong choice.

Phrased that way rather than “am I right?”, which you now know produces agreement.

5. Decide yourself, and write down why.

One paragraph: what you chose, on which criteria, and what would make you revisit. In six months that paragraph is worth more than the comparison.

Watch for the invented specification

The most common factual failure in this task is a plausible product detail (a price tier, an integration, a limit) that is out of date or was never true. Product pages change constantly and training data does not.

Two defences. Require a source or a link for every factual claim. And check the two or three facts your decision actually turns on, on the vendor’s own page, today. Not all of them; the ones carrying the decision.

Where the comparison helps

Making the criteria explicit. Half of most decisions is discovering that two people in the room are optimising for different things. A table forces that into the open.

Finding the third option. “What are we not considering, including doing nothing and building it ourselves?”

Pricing the trade-off. “If we choose the cheaper one, what specifically do we give up, and what would it cost to add it back later?”

Writing it up for somebody else. Once you have decided, the comparison is the document that explains it to a board or a partner.

The decision is not the output

A model can hold more of the comparison in view than you can and has no stake in it. It also has no knowledge of your politics, your history with a vendor, or the fact that one option requires a colleague who will resist it.

Those things frequently decide it, correctly. Do not treat their absence from the analysis as a reason to discount them.

The trap of the tidy table

A comparison table is persuasive out of proportion to what it contains. Five criteria, three columns, everything filled in: it looks like the decision has been made rigorously.

But the criteria were chosen by you in ten seconds, the weights are invisible, and the cells marked “not stated” are quietly counted as neutral when they may be the most important thing on the page. A supplier who will not state a lead time has told you something, and a blank cell does not carry it.

Read the empty cells before the full ones. They are where the information usually is.