Record Why Each Supplier Left the Shortlist

Your next evaluation will inherit today's missing context

A technology advisor starts with six possible suppliers, narrows the list to three, and recommends one. The client approves the direction. The proposal is signed. Everyone moves on.

Then the recommended supplier misses a contract condition. A stakeholder asks whether the runner-up could replace it. Six months later, another client needs a similar service. Somebody suggests a supplier that the firm already evaluated and removed.

Now the team is searching email and meeting notes for an answer. Was the supplier too expensive? Unable to meet a security requirement? Weak in one geography? Late with evidence? Or simply not right for that client's timeline?

If you cannot answer that quickly, the shortlist did not produce a reusable decision record. It produced a winner and discarded the rest of the work.

Do not turn every removal into a permanent judgment

"Rejected vendor" is usually too blunt. A supplier can leave one evaluation for several different reasons, and those reasons should not all follow it forever.

A supplier may fail a nonnegotiable client requirement. It may remain capable but lose on commercial fit. It may provide incomplete evidence before the deadline. The client may change the project. The advisor may pause the evaluation before the supplier finishes its response.

Those are different decisions. One says the supplier could not meet the need. Another says a different option fit better. Another says the evidence was not ready. If you collapse all three into "not selected," the next advisor cannot tell what deserves another look.

Microsoft's current Dynamics 365 quote guidance makes a useful distinction among quotes closed as lost, canceled, or revised. It also preserves a close date and description. That is sales software documentation, not a complete supplier evaluation model, but the operating lesson holds: status, reason, timing, and revision are separate facts.

Use a small set of exclusion reasons

Do not create a list of forty reasons nobody uses consistently. Start with categories that change what your team does next.

• Requirement gap: The supplier could not meet a confirmed client requirement.
• Evidence gap: The supplier may fit, but the team did not receive enough proof to advance it.
• Delivery risk: Implementation ownership, timing, support, staffing, or dependencies exceeded the client's tolerance.
• Commercial mismatch: Pricing, term, minimum commitment, implementation cost, or contract structure did not fit.
• Client preference: The client made a documented tradeoff among otherwise credible options.
• Evaluation change: The project, scope, architecture, budget, or timing changed before a fair comparison finished.
• Advisor operating constraint: The firm could not responsibly support the supplier path with its current access, expertise, or service model.

The category is only the start. Add one plain sentence stating the exact issue. "Delivery risk" tells the team where to look. "Supplier could not confirm porting ownership for the January migration window" tells them what happened.

Tie the reason to evidence and a requirement

An exclusion reason should point back to the client's decision, not the advisor's mood.

Record the client requirement or evaluation criterion, the supplier response, the evidence reviewed, who confirmed the decision, and the effective date. If the team relied on a demonstration, quote, email, contract clause, reference call, or implementation plan, link or identify it. If the evidence came from the supplier and remains unverified, say that.

This protects the decision from two common problems. The first is revisionist history, where a stakeholder later remembers a different reason. The second is supplier folklore, where one bad fit becomes a firmwide statement that the supplier is bad at everything.

Microsoft's current supplier relationship guidance separates discovering suppliers, onboarding them, managing active relationships, evaluating performance, compliance, risk, contracts, and pricing. That separation matters here. Evidence from an existing supplier's service history can inform a new evaluation, but a previous performance issue should not silently replace the current client's requirements.

Name what would allow the supplier to reenter

Some decisions are final for the current project. Others should have a reentry rule.

A supplier removed for a missing integration might reenter after providing current technical documentation and a working demonstration. One removed for geography may reenter if coverage expands. One removed because the client paused the project may deserve a new review when funding and timing return.

Write the reentry event beside the exclusion reason. Include who owns verification and whether the supplier can return to the current evaluation, a future evaluation, or neither.

Do not set a fake reminder to "check back in six months" if time alone changes nothing. The trigger should be evidence: a product release, a documented service-area change, a revised commercial term, a resolved support issue, or a new client requirement.

Separate the internal record from the client explanation

Your internal record may include partner economics, support history, incomplete references, sensitive pricing, or concerns that require careful wording. The client still needs a clear explanation of why the shortlist changed, but that does not mean forwarding every internal note.

Create a client-safe decision statement tied to the agreed criteria. For example: "We did not advance this option because the supplier could not confirm implementation ownership inside the required migration window." That is more useful than "not a fit" and safer than sharing speculation or another supplier's confidential terms.

If the client overrules the evaluation, record that too. Preserve the advisor's recommendation, the client's decision, the accepted tradeoff, and any condition that still needs protection. Do not rewrite the scorecard after the meeting to make the final choice look inevitable.

Keep the supplier record and opportunity record connected

The same supplier can be excluded from one opportunity and recommended for another. Store the evaluation decision with the client and opportunity, then connect it to the broader supplier history.

The opportunity record should answer what happened in this decision. The supplier record should help the firm see patterns across decisions. Are delivery concerns repeating? Does the supplier consistently fit a certain client profile? Are evidence gaps getting resolved? Is one advisor excluding a supplier for reasons nobody else applies?

This is also why a closed opportunity should keep its decision history. Microsoft's opportunity closure guidance preserves competitor, close date, description, and a closed activity that managers can inspect later. Your advisory record needs the same basic discipline at the supplier-option level, not only at the final deal level.

Review the decision before you reuse it

A prior exclusion is evidence, not an automatic answer for the next client.

Before reusing it, check whether the client requirement is the same, the supplier information is still current, and the original evidence was strong enough. Confirm whether product, coverage, pricing, ownership, support, or contract terms changed. Keep the old decision intact and add the new one. Do not overwrite history until it tells a cleaner story than reality.

This deepens the operating step in the supplier selection process: every option that leaves the shortlist gets a reason, evidence, decision owner, date, and reentry rule. The final recommendation then moves into a client decision brief without erasing the path that produced it.

Start with the last recommendation you made

Open the last client evaluation with more than one credible supplier. List every option considered. For each supplier that did not advance, write the exact reason, supporting evidence, decision owner, client-safe explanation, and reentry condition.

If the team cannot reconstruct those fields, do not invent them. Mark the record incomplete. Then change the process so the next shortlist closes each option while the evidence is still fresh.

Advisor OS CRM connects clients, opportunities, suppliers, proposals, activities, tasks, owners, and reporting. Use that connected history to keep a supplier decision attached to the client requirement that made it true.

Use the free Advisor OS agency scorecard if supplier evaluations still disappear into proposal folders, email threads, and one advisor's memory.