Build a review evidence table for a supplier shortlist

A review evidence table turns scattered comments into a set of questions you can compare fairly. It should record where a claim came from, when it was made, which service it describes and what you still need to verify. The aim is not to calculate a secret score; it is to stop vivid anecdotes from outweighing more relevant evidence.

Choose columns that answer a decision question

Start with supplier, source, date, service, reviewer's claim, strength of detail and follow-up. Add a column for whether the same account appears elsewhere. Keep the original wording or a short neutral summary, not your conclusion. For example, “reviewer says the handover files arrived late” is more precise than “poor company”.

Include the plan or service tier. A complaint about a premium package may not describe the basic option you are considering, and vice versa.

Record uncertainty openly

Mark whether the account is first-hand, whether the date is clear and whether the outcome can be checked. You may not be able to verify everything. Use a simple note such as “specific but uncorroborated” rather than forcing a numerical confidence value.

If a review is copied across platforms, record it once. Counting it twice makes a theme look more common than it is.

Group themes before comparing companies

Once you have recorded a manageable sample, group claims about communication, delivery, support and billing. Look at both positive and critical accounts. Do not hide an important serious issue inside an average score, but also avoid treating one complaint as a repeated pattern.

The supplier due diligence checklist provides the next step: checking material review themes against current evidence and contract terms.

Turn each theme into a neutral question

If several comments mention slow support, ask each supplier how tickets are prioritised, when customers are updated and which tier those terms cover. Record the answer beside the review theme. Keep your final shortlist note short enough for another decision maker to read; the table is there to support judgement, not bury it.

Example row: make the claim precise

Suppose a review says, “Support was slow after our launch.” A useful row records the source, date, service tier if known, the reported delay and whether the customer later received a resolution. The follow-up question becomes: “What update schedule applies to an unresolved launch issue on our proposed plan?” Do not write “supplier has poor support” in the claim column. That is a conclusion you have not yet supported. The table stays useful because another decision maker can see the original concern and the question it generated.

Frequently asked questions

How many reviews should go in the table?

Use enough relevant, distinct accounts to understand the themes. A large sample of generic comments may add little value. Stop when new accounts are repeating the same relevant themes without adding useful context.

Should I include positive reviews too?

Yes. They can reveal strengths and show whether a concern is isolated or recurring. Apply the same relevance checks to praise.

Is the table a rating system?

No. It is an evidence log. You may later score suppliers against requirements, but the source and uncertainty should remain visible.