Treat required criteria as gates, record evidence for each score, and leave unresolved facts blank until they are verified.
This is an original planning framework. Examples illustrate the method; they are not product ratings or measured business results.
A candidate can score well on convenience and still fail because it cannot export a required record. The score is useful only after you check the non-negotiable conditions. This original editorial framework is a way to structure that decision; it is not a validated industry standard or a recommendation for a particular product.
Download the software evaluation scorecard CSV. The file provides rows to fill in; it does not calculate scores automatically. For a product-specific example of comparing a workflow from documentation, see Zapier vs. Make for small businesses. The essential software stack guide helps identify which job needs evaluating in the first place.
Start with gates, then preferences
Write down the conditions that must be true before scoring. A required criterion should be phrased so the answer can be checked: “Can an authorized user export the project records in a usable format?” is more useful than “Good data portability.”
If a candidate fails a true requirement, mark it blocked. Do not let strong marks elsewhere average away the failure. If you discover that a supposed must-have is negotiable, record why and who agreed to change it; otherwise, the gate stops being a gate.
Fill in the CSV fields
The downloadable file uses these columns: Candidate, Criterion, Required, Weight, Score, Evidence URL, Checked date, Plan, and Notes. Use one row for each candidate and criterion. Add a new row rather than squeezing several requirements into one cell.
Set Required to yes or no. Set Weight from 1 to 3, where 3 means the criterion matters more to this decision. Set Score from 0 to 3: 0 means the candidate does not meet the criterion; 1 means it meets it poorly or with a material limitation; 2 means it meets the need with a manageable caveat; 3 means it meets the stated need based on the evidence you recorded.
For each required row, write the acceptance condition and minimum acceptable score in Notes before assessing candidates. For example, a complete usable export may require a score of 3. Required rows remain in the weighted calculation, but each must also pass its own gate. Duplicate the same set of rows for each candidate. The sample criteria and weights in the CSV are starting points; agree your own before comparing tools.
Keep a score tied to a specific criterion, not a general impression. Use the evidence URL and checked date to point to a current product document, quote, or other relevant record. Put the exact plan or tier checked in Plan; availability can vary by plan. Use Notes for caveats, unanswered details, or the name of the person following up.
Leave unknown answers blank
An unresolved answer is not a zero. Zero means you have enough evidence to conclude the tool does not meet the criterion. Blank means the team does not yet know.
Until the blank is resolved, the candidate cannot pass a required gate. For any scored criterion, do not silently omit the row from the denominator: pause the final comparison and show which information is missing. A research note can remain provisional, but do not select a winner from incomplete totals.
Calculate the score by hand
Once every scored row has an evidence-backed answer, calculate across the same complete set of criteria for each candidate:
Total = sum(weight × score) / (3 × sum(weights)) × 100
The result is a percentage of the maximum weighted score. The CSV contains no formulas, so calculate it separately and write the result in your decision notes. Keep the candidate’s raw score and the gate outcome visible alongside the percentage.
Here is a hypothetical example with three scored criteria. The numbers are illustrative and do not describe real products:
| Criterion | Weight | Candidate score | Weighted points |
|---|---|---|---|
| Supports the core handoff | 3 | 3 | 9 |
| Exports the records needed | 2 | 2 | 4 |
| Fits the team’s review routine | 1 | 1 | 1 |
| Total | 6 | 14 |
The maximum is 3 × (3 + 2 + 1) = 18. The result is 14 / 18 × 100 = 77.8% when rounded to one decimal place. If exporting the records were a required criterion and the score of 2 failed your defined gate, the candidate would remain blocked despite the percentage.
Compare like with like
Use the same criteria, weights, and scoring meanings for each candidate. Check the relevant plan for each one and date the evidence. If one candidate has a verified answer and another has an unresolved question, keep the unknown visible instead of awarding an assumed tie.
The scorecard is a thinking aid, not a substitute for checking the work you need to do. Read documentation that addresses the actual workflow, and ask the provider about a material ambiguity. If you need a direct comparison, the Zapier and Make workflow comparison shows how to frame questions around one process.
Record the decision and its conditions
Write a short decision note with the selected candidate, the reason it passed required gates, the strongest trade-off, unresolved questions, and the date to revisit the choice. If the decision is conditional, name the condition and the person responsible for confirming it.
This makes the result understandable when a plan changes or the original evaluator is unavailable. Revisit the score when the workflow changes, a requirement changes, or a key piece of evidence is no longer current. The scorecard helps explain the choice; it cannot guarantee that a tool will remain suitable.
References & research notes
This article presents an original editorial framework. Its examples and criteria are illustrative, with no product-specific performance claims.
Read our editorial and update policy