Free XLSX workbook · Account-free
Sales AI Vendor Scorecard: Evidence, Hard Gates, Pilot, and TCO
A Sales AI vendor scorecard with hard gates, evidence states, anchored criteria, reproducible tests, workload-adjusted cost, and decision expiry.
- Method owner
- Anastasiia Krynytska
- Reviewed
- 10 Sep 2026
- Reading
- 9 min read
Practical answer
What this resource does
Use the scorecard to compare viable products for one bounded workflow without allowing points to erase a failed authority, data, security, or reversibility gate.
- No lead gate. Open, calculate, or download directly.
- Visible method. Definitions, formulas, ownership, and invalid states stay inspectable.
- Human authority. The asset supports a decision; it never owns one.
A vendor scorecard should make a buying decision inspectable. It should not convert a polished demo into a precise-looking total or allow a strong feature score to compensate for a failed security, legal, data, authority, or reliability gate. This workbook compares Sales AI products against one declared workflow, using dated evidence and a controlled test.
The downloadable workbook contains nine tabs: Decision Setup, Requirements, Hard Gates, Evidence Register, Weighted Scorecard, Test Protocol, Total Cost, References, and Decision Log. It supports one-vendor assessment and N-way comparison without hiding missing evidence. The file is account-free and intended for local or user-controlled storage.
Use the operational checklists for a lighter preflight. Use this scorecard when the decision requires comparative evidence, a controlled pilot, cost modeling, and a durable approval record.
Gong’s AI sales technology evaluation guide illustrates common evaluation questions. The NIST AI Risk Management Framework and its generative-AI profile provide a broader risk vocabulary. This Luck My Sales scorecard adds evidence-state accounting, non-compensable gates, standard test inputs, price authority, workload-adjusted TCO, dissent, and expiry. It does not certify a product or replace legal, security, accessibility, finance, or procurement review.
01 / Method
Step 1: define the decision and workflow
Start with the decision, not a vendor shortlist. State what the organization may authorize, for which team and workflow, by what date, at what maximum exposure, and with what fallback. A broad goal such as “use AI for sales” cannot produce testable requirements.
The Decision Setup tab requires:
- decision ID, version, sponsor, Decision Owner, and deadline;
- workflow trigger, inputs, transformations, output, consumer, and action;
- current baseline, pain, desired outcome, and guardrails;
- eligible users, records, regions, languages, and explicit exclusions;
- systems of record and required integrations;
- maximum budget, contract horizon, pilot boundary, and exit route;
- all five roles: Decision Owner, Operator, Data Owner, Security/Legal Reviewer, and Action Owner.
Map human authority before assessing automation. Identify who may approve pricing, outbound messages, record updates, data deletion, forecast changes, customer commitments, and model-driven actions. A vendor feature is not acceptable merely because it can automate the task. The organization must decide whether it should.
The workflow-fit statement follows a fixed form: “When [trigger] occurs for [eligible population], the product may use [permitted inputs] to produce [bounded output], which [human/system] reviews before [action], with [fallback] when [failure] occurs.” This becomes the basis for requirements and test cases.
02 / Method
Step 2: classify requirements
Requirements are atomic, observable, and tied to a decision. “Good integration,” “enterprise-ready,” and “accurate AI” are not testable. Rewrite them as behavior: for example, “When a duplicate contact arrives by webhook, the system must preserve the authoritative CRM ID, record the source, and route the exception without creating a second active record.”
Each requirement stores ID, category, text, rationale, priority, hard-gate status, evidence required, test method, owner, and expiry. Suggested categories are workflow fit, output quality, latency, reliability, data governance, security, privacy, human control, integrations, administration, accessibility, implementation, support, commercial terms, and exit.
Use Must, Should, and Could for scope, but do not turn these labels directly into vendor points. A Must may be a hard gate or a weighted criterion; the Decision Owner must say which. Separate a required outcome from a preferred implementation so vendors can demonstrate a credible alternative.
03 / Method
Step 3: establish non-compensable hard gates
A hard gate returns Pass, Conditional pass, Fail, or Not evaluated. It never contributes points to the weighted score. Fail and Not evaluated block the decision when the requirement is non-compensable. A conditional pass requires a documented control, owner, deadline, and retest.
Baseline gate groups include:
- Authority and commercial truth. The product cannot invent or autonomously approve prices, discounts, contractual promises, or policy exceptions. Approved sources, expiry, escalation, and audit records are testable.
- Personal and confidential data. Permitted data classes, locations, subprocessors, training use, retention, deletion, export, access, and incident duties are documented and contractually reviewable where applicable. In GDPR scope, assess processor terms against the official Article 28 text.
- Identity and access. Authentication, role boundaries, least privilege, joiner/mover/leaver handling, service accounts, logs, and privileged actions fit the environment.
- Human intervention. Users can inspect evidence, approve consequential actions, pause automation, correct a record, and route uncertainty. A human gate that exists only in documentation does not pass the operational test.
- Reliability and recovery. Failure is detectable; retries are bounded; duplicate actions are prevented; incidents can be contained; data can be reconciled; a fallback exists.
- Exit and portability. The organization can export needed records and configurations, revoke access, delete data according to terms, and continue the workflow without unacceptable lock-in.
For voice AI, the owner specification adds an end-to-end interaction target below 800 ms for the declared measurement path. Treat this as a Luck My Sales house requirement, not a universal proof of conversational quality. Measure microphone input to audible response under declared network, model, telephony, region, load, and percentile conditions. Average component latency cannot substitute for the end-to-end distribution.
For price-sensitive generation, test hallucination guardrails using known, expired, missing, conflicting, and unauthorized pricing inputs. The safe output should cite the approved price source or refuse and escalate. A correct answer on one happy-path prompt does not establish the gate.
For personal data, prefer minimization and local or controlled anonymization where feasible. Test whether identifiers are removed before a model or downstream service receives them, whether re-identification keys are separated, and whether logs or support traces reintroduce the data. “PII masking available” is a feature claim until the actual path is inspected.
04 / Method
Step 4: keep an evidence register
Every evaluation claim links to a record. The Evidence Register stores evidence ID, vendor, criterion, claim, evidence type, source URL or file, source owner, observed date, product version, environment, evidence state, limitations, reviewer, and expiry.
Use these evidence states:
- Observed in our test: reproduced by the buyer under a declared protocol.
- Contractual: present in the reviewed agreement or order form.
- Vendor-documented: present in current official documentation.
- Vendor-asserted: stated in a call, questionnaire, or message without stronger verification.
- Independent external: dated, relevant third-party evidence.
- Inferred: analyst interpretation from other evidence.
- Unknown: no adequate evidence.
- Contradicted: material evidence conflicts.
Scores cannot convert Unknown to zero and then hide it in an average. Report evidence coverage separately: requirements with decision-grade evidence divided by requirements in scope. A vendor can have a high provisional weighted result and low evidence coverage; the decision page must show both.
Screenshots should preserve date, visible product state, and context. Recordings require appropriate handling. Vendor documentation may change, so store a source snapshot or dated reference where permitted, a last-verified date, and a reviewer. Never imply that a public trust page proves configuration in the buyer’s tenant.
05 / Method
Step 5: use a transparent weighted score
Weighted scoring ranks options only after hard gates. Define one anchored scale across vendors:
- 0 — Does not meet: observed failure or material contradiction.
- 1 — Material gap: partial capability with high workaround or risk.
- 2 — Meets with constraint: acceptable only with declared limitation or operating work.
- 3 — Meets: requirement satisfied under the test conditions.
- 4 — Exceeds materially: verified benefit beyond the requirement that changes the decision.
The normalized weighted result is:
Sum(score ÷ 4 × weight) ÷ sum(applicable weights) × 100.Do not score Not applicable. Do not score Unknown unless the governance rule explicitly applies a visible uncertainty penalty; even then, keep Unknown counts separate. Weights total 100 within the current decision, not across every imagined use case. Sensitivity analysis should show whether a reasonable weight change reverses the ranking.
Each criterion needs an evidence link and reviewer note. The workbook calculates totals but does not print “best vendor.” The Decision Owner interprets fit, gates, evidence coverage, uncertainty, TCO, concentration, implementation burden, and reversibility.
06 / Method
Step 6: run a reproducible pilot
A pilot tests the bounded workflow against the baseline; it is not a discounted production rollout. The Test Protocol tab defines environment, eligible population, sample construction, standard inputs, expected behavior, prohibited behavior, success measure, guardrail, observation window, adjudication, and stop rule before the vendor sees the result.
Include normal, edge, adversarial, ambiguous, missing-data, conflicting-source, outage, permission, duplicate, and rollback cases. For generated sales content, test factuality, source use, unsupported claims, price authority, privacy leakage, tone constraints, and refusal. For enrichment, test match precision, provenance, staleness, overwrite behavior, and duplicate handling. For conversation intelligence, test speaker separation, terminology, incomplete recordings, inference labeling, timestamps, and export.
Track task outcome and operating cost. A product can improve output quality but create excessive review, exception, and administration work. Record human minutes per case, escalation rate, correction rate, failure severity, and affected population. Do not extrapolate a small controlled sample to every user or segment without a plan to verify transfer.
The pilot record distinguishes product failure, integration failure, configuration failure, source-data failure, operator error, and unknown cause. This protects the analysis from both excusing every failure and attributing every system issue to the model.
07 / Method
Step 7: calculate total cost at realistic scale
The Total Cost tab models year-one and steady-state cost for at least three scales, such as 1×, 3×, and 10× the pilot workload. Visible inputs include platform fee, seats, usage units, minimum commitment, AI add-on, implementation, integration, security/legal review, migration, training, administration, human review, exception handling, overage, support, and exit.
Record currency, tax treatment, billing period, contract term, renewal assumption, price source, verified date, and confidence. Custom quotes remain custom quotes; do not fabricate a list price. Separate cash outlay from internal labor and opportunity cost.
Unit cost should match the workflow: per accepted contact, reviewed call, resolved record, qualified meeting, or other output—not merely per generated item. Use low, base, and high scenarios with transparent drivers. Do not assume pilot discounts or included services persist at scale.
08 / Method
Step 8: decide with dissent and expiry
The Decision page shows hard-gate state, weighted result, evidence coverage, pilot outcome, TCO scenarios, material limitations, reversible and irreversible commitments, recommendation, dissent, and next review. Allowed decisions are Approve, Approve controlled pilot, Conditional approval, Hold for evidence, or Reject for this workflow.
“Reject for this workflow” is deliberately narrower than “bad product.” A strong product can be wrong for the population, systems, authority model, or current capacity. Likewise, the highest weighted score can lose when a lower-scoring option is safer, better evidenced, easier to reverse, or materially cheaper to operate.
Preserve dissent. Record the reviewer’s concern, supporting evidence, condition that would resolve it, and Decision Owner’s response. Give every approval an expiry or review trigger: material product change, new subprocessor, integration change, incident, scope expansion, pricing change, model-version change, or scheduled reassessment.
09 / Method
Illustrative comparison
Suppose Vendor A scores 84/100 with 58% evidence coverage and an unevaluated deletion gate. Vendor B scores 77/100 with 92% evidence coverage, passes every hard gate, and has higher year-one implementation cost but lower review labor at scale. The workbook does not crown Vendor A. It shows that A is blocked pending gate evidence and that cost depends on the declared workload. The Decision Owner may pilot B, hold both, or collect more evidence.
This example is not a benchmark. Its purpose is to show why points, evidence, gates, and costs remain separate.
10 / Method
Frequently asked questions
How many criteria should a scorecard contain?
Enough to represent the bounded decision, but each criterion must be testable and material. Consolidate overlapping feature wishes; split requirements that need different evidence or owners.
Can a vendor complete the scorecard?
A vendor can provide claims and evidence, but the buyer owns scope, classification, testing, applicability, and decision. Label vendor-supplied states until verified.
Should security questionnaires be scored?
Use them as evidence inputs. Critical requirements belong in hard gates or specialist review, not a feature average.
Does the workbook store submitted vendor data?
No. The file is designed for local or user-controlled use. Luck My Sales does not require an account or email to download it.
When should a scorecard be renewed?
At the declared review date and whenever a material product, model, processor, integration, price, incident, or workflow change invalidates prior evidence.
Method owner: Anastasiia Krynytska, RevOps Architecture Lead. Reviewed 10 September 2026. This is an evaluation framework, not certification or legal, security, or financial advice.
Method & privacy note
Inspect before you act
- The complete approved editorial text is published on this page, not hidden behind the download or interface.
- Calculator inputs stay in browser memory; workbook contents stay wherever the user saves them.
- Unknown, unavailable, contradicted, and not applicable remain distinct states.
- Corrections: corrections@aiinsales.org.