Vendor Selection Reasoning Chain

validated business chain v1.0.0 cc-by-sa

Block ID: c6a00800-9e4b-41b9-bf4b-22b8815e0859

Community-contributed block. PromptDNA makes no guarantee of output quality or fitness for purpose. User assumes all responsibility for use.

Template

Reason through selecting a vendor for the need in {vendor_need}, weighing total cost and fit over the sticker price. (1) Define the requirements first and separate the must-haves from the preferences, because evaluating vendors against a fuzzy spec lets sales presentations rather than your needs drive the choice — and the requirements should come from the users of the thing, not only the buyer. (2) Compute total cost of ownership, not just price: implementation, integration, training, ongoing fees, and the switching cost to leave — the cheapest quoted option frequently costs the most over its life, and this is the dominant procurement error. (3) Weigh the requirements-fit against cost explicitly, scoring each finalist on how well it meets the must-haves, and disqualify any that misses a must-have regardless of price. (4) Assess the vendor's viability and the relationship risk: their stability, support quality, roadmap alignment, and how dependent this makes you — a cheap vendor who fails or holds your data hostage is expensive. (5) Consider lock-in and exit: how hard it is to leave, data portability, and contract terms that trap you. (6) State the recommended vendor, the tradeoff accepted, and the biggest risk to manage in the contract — noting where a proof-of-concept or reference check would resolve remaining doubt before committing.

Reason through selecting a vendor for the need in {vendor_need}, weighing total cost and fit over the sticker price. (1) Define the requirements first and separate the must-haves from the preferences, because evaluating vendors against a fuzzy spec lets sales presentations rather than your needs drive the choice — and the requirements should come from the users of the thing, not only the buyer. (2) Compute total cost of ownership, not just price: implementation, integration, training, ongoing fees, and the switching cost to leave — the cheapest quoted option frequently costs the most over its life, and this is the dominant procurement error. (3) Weigh the requirements-fit against cost explicitly, scoring each finalist on how well it meets the must-haves, and disqualify any that misses a must-have regardless of price. (4) Assess the vendor's viability and the relationship risk: their stability, support quality, roadmap alignment, and how dependent this makes you — a cheap vendor who fails or holds your data hostage is expensive. (5) Consider lock-in and exit: how hard it is to leave, data portability, and contract terms that trap you. (6) State the recommended vendor, the tradeoff accepted, and the biggest risk to manage in the contract — noting where a proof-of-concept or reference check would resolve remaining doubt before committing.

Variables

Name	Type	Required	Trust level
vendor_need		yes

procurementvendor-selectionevaluationchain-of-thought

Ratings

0.0

Overall (0)

0.0

Accuracy

0.0

Consistency

0.0

Clarity

0.0

Efficiency

Benchmarks

Not yet self-validated against any benchmark. Automated, evaluative only - not a factor in whether this block was published.

Submitted by James P FounderMod via mcp · 2026-07-18