Independent operator-led media on AI in B2B sales

Operating checklists · Account-free

Sales & RevOps Checklists: Five Evidence-Based Operating Reviews

Five evidence-based operating reviews for Sales AI evaluation, CRM hygiene, pipeline, coaching, and GTM launch readiness.

Method owner: Anastasiia Krynytska
Reviewed: 10 Sep 2026
Reading: 14 min read

Approved Phase 12 visual · informational, not a performance claim.

Practical answer

What this resource does

Each checklist turns a box into an operating control by naming acceptable evidence, an accountable role, a failure condition, and the required output.

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 checked box is not evidence. Each checklist below defines the control, what proves completion, who owns the decision, what failure looks like, and which action must follow. Use one module at a time. Copying all five into a single meeting creates ceremony without control.

These are Luck My Sales operating checklists, not universal standards. Numeric thresholds such as <800 ms, 45 days, 45/55, and <0.5% are configurable house targets. Keep the threshold only when it matches the workflow, population, risk, and available evidence. Security, privacy, and legal decisions remain with the responsible human reviewer.

01 / Method

How to record a checklist result

Every row needs six fields: status, evidence link or record, reviewer, review date, failure or exception, and next action. Use these states:

Verified: direct evidence meets the stated control.
Vendor-claimed: a supplier states that the control exists, but the team has not reproduced it.
Unknown: required evidence is absent or inaccessible.
Not applicable: the control does not apply, with a written reason and approver.
Failed: evidence shows the control is not met.

Unknown is not a pass. Not applicable is not a blank. A failed hard gate cannot be offset by several easy passes.

**Five operational checklist modules.** Every module uses the same evidence-to-owner-to-decision control core.

02 / Method

Checklist 1: Sales-AI evaluation

Purpose: decide whether a Voice AI, LLM parser, note-taker, scoring system, or agent belongs in a specific revenue workflow. NIST’s AI Risk Management Framework treats AI risk work as an ongoing govern-map-measure-manage cycle, not a one-time feature review. The NIST Generative AI Profile adds risks and actions that teams can tailor to acquisition and use.

Scope and authority

Name one workflow and one business decision. Evidence: current-state map, record types, triggering event, output, consumer, and system of record. Owner: Decision Owner. Failure: the vendor is being evaluated as a generic “AI platform.” Output: bounded evaluation statement.
Name every action the tool may take. Evidence: permissions and tool list covering read, draft, send, write, delete, price, stage, and export. Owner: Operator with Security/Legal review. Failure: demo permissions differ from planned production permissions. Output: allow/deny matrix.
Define the human gates. Evidence: reviewer, required context, decision options, service expectation, and fallback. Owner: Decision Owner. Failure: “human in the loop” exists only as a slogan. Output: release-gate map.

Performance and failure behavior

Measure latency at the workflow boundary. Evidence: repeated p50, p95, and p99 measurements under the declared region, network, concurrency, payload, and tool chain. Owner: Operator. House target for a voice workflow: <800 ms at the declared boundary. Failure: only a vendor average or model-only latency is available. Output: reproducible test record.
Test pricing and commercial guardrails. Evidence: adversarial scenarios that request invented discounts, contract terms, guarantees, and unsupported product claims. Owner: Decision Owner. Failure: the system produces buyer-facing commercial content not grounded in approved records. Output: blocked-output log and corrected control.
Run representative and failure-first scenarios. Evidence: common inputs, ambiguous inputs, missing fields, stale data, prompt injection, tool failure, timeout, and conflicting source records. Owner: Operator and Data Owner. Failure: evaluation contains only successful demo cases. Output: scenario-level pass/fail table.
Separate model quality from workflow quality. Evidence: task result, source traceability, human correction time, action success, and downstream record accuracy. Owner: Data Owner. Failure: one subjective “AI quality” score hides different failure modes. Output: metric contract per test.

Data, security, economics, and exit

Map every data transfer. Evidence: field-level input/output map, processor/subprocessor list, region, retention, training use, deletion path, and log access. Owner: Data Owner and Security/Legal Reviewer. Failure: PII destinations or retention are unknown. Output: approved data-flow diagram.
Minimize or anonymize PII before API transfer where feasible. Evidence: transformation rule and test showing what leaves the controlled environment. Owner: Data Owner. Failure: raw personal data is sent because the demo used it. Output: minimization control or approved exception.
Verify contract and processing terms. Evidence: executed or review-ready DPA, security materials, subprocessor terms, incident commitments, and deletion language. Owner: Security/Legal Reviewer. GDPR Article 28 establishes requirements for controller-processor contracts where applicable. Failure: a public privacy page is treated as the executed agreement. Output: legal/security decision record. This is not legal advice.
Model total cost at current, 3×, and 10× volume. Evidence: seats, usage units, add-ons, API/model cost, implementation, integration, monitoring, evaluation, training, human review, and exit work. Owner: Decision Owner. Failure: list price is the only cost. Output: scenario TCO.
Test reversibility. Evidence: data export, deletion confirmation, prompt/config export, replacement workflow, contract exit, and rollback drill. Owner: Action Owner. Failure: the process cannot operate if the vendor is unavailable. Output: exit and rollback plan.

Decision output: approve a bounded pilot, reject, or request missing evidence. Do not approve production from the weighted score alone.

03 / Method

Checklist 2: CRM hygiene

Purpose: keep account, contact, opportunity, activity, and ownership records reliable enough for the decisions they support. CRM hygiene is a recurring control, not a cleanup project. Salesforce’s data-cleaning guidance highlights scope, standard vocabulary, and duplicate review; this checklist adds ownership and failure actions.

Identity and ownership

No active account lacks a Company Owner. Evidence: query of active accounts with null, inactive, or unauthorized owners. Owner: Data Owner. Failure: any in-scope account lacks an accountable owner. Output: assignment queue and root-cause count.
Every webhook entry normalizes and evaluates Domain. Evidence: webhook test cases for corporate, free-mail, missing, malformed, internationalized, and redirected domains. Owner: Operator. Failure: raw domains write directly to the canonical field. Output: transformation and exception log.
Duplicate checks run before create and after enrichment. Evidence: exact and fuzzy rules, survivorship logic, sampled precision, and merge audit. Owner: Data Owner. Failure: the tool returns a “match” without proving entity identity. Output: potential-duplicate queue, not automatic destructive merge.
Source authority is explicit. Evidence: field-by-field precedence for buyer response, CRM entry, enrichment, product data, contract, billing, and Finance. Owner: Data Owner. Failure: the newest integration silently overwrites stronger evidence. Output: source-authority table.

Required fields and lifecycle

Critical fields have stage-specific completeness rules. Evidence: rule set for amount basis, close date, next step, owner, qualification evidence, and loss reason. Owner: Operator. Failure: completeness is measured across decorative fields while decision fields remain blank. Output: actionable exception list.
Stage changes preserve evidence and history. Evidence: stage-entry timestamp, actor, required criteria, and previous value. Owner: Data Owner. Failure: bulk automation rewrites stages without an audit trail. Output: stage-change audit.
Inactive deals enter a governed review path after 45 days. Evidence: last meaningful buyer activity, next step, seller explanation, manager disposition, and exception expiry. Owner: Action Owner. Failure: the deal remains open because an automated email reset the clock. Output: retain, requalify, move period, close-lost, or archive decision. The 45-day threshold is configurable.
Closed-lost records require a usable reason. Evidence: controlled reason, short note, competitor/alternative when known, and final decision date. Owner: Operator. Failure: “other,” blank, or blame-oriented text dominates. Output: corrected taxonomy and coaching action.

Monitoring and correction

Track missingness, duplicates, invalid values, and staleness separately. Evidence: count, eligible population, rate, trend, and top source. Owner: Data Owner. Failure: a composite health score hides which control failed. Output: four diagnostic measures.
Sample correctness, not only completion. Evidence: stratified review of high-value, recent, and integration-created records. Owner: Data Owner. Failure: a populated field is assumed correct. Output: error type and correction plan.
Close the loop with the creating workflow. Evidence: defect traced to form, import, webhook, integration, UI, automation, or user action. Owner: Action Owner. Failure: cleanup repeats without changing the source. Output: preventive control and verification date.

Decision output: accept current quality for a named use, restrict the decision, or block the downstream workflow until the critical defects are corrected.

**The checklist control chain.** A checkbox becomes a usable operating control when evidence, authority, failure, and output are explicit.

04 / Method

Checklist 3: Pipeline review

Purpose: inspect whether the pipeline is real, decide what changes, and update the CRM. It is not a meeting where sellers read fields aloud. Salesforce’s pipeline-review guidance emphasizes stage exit criteria and named actions; the Luck My Sales method adds MEDDPICC evidence and a buyer-agreed MAP.

Pre-work

Freeze the review snapshot. Evidence: timestamp, currency, period, target, gross open pipeline, qualified pipeline, and previous-week comparison. Owner: Data Owner. Failure: figures change during the meeting without a recorded reason. Output: review baseline.
Calculate house coverage from qualified pipeline only. Evidence: opportunity-level qualification status and amount basis. Owner: Operator. Failure: every CRM deal enters the numerator. Output: gross and qualified coverage shown separately.
Surface only decision-relevant exceptions. Evidence: close-date movement, stage regression, inactivity, amount change, missing next step, missing buyer role, and new risk. Owner: Action Owner. Failure: agenda is sorted only by deal size. Output: prioritized inspection queue.

Deal evidence

Confirm the Economic Buyer. Evidence: direct contact, verified decision authority, or an explicit path to the person who holds it. Owner: Operator. Failure: title seniority is treated as proof. Output: confirmed role or access action.
Validate Technical Decision Criteria. Evidence: applicable security review, sandbox result, integration constraint, data requirement, and named technical approver. Owner: Security/Legal Reviewer where applicable. Failure: “technical fit” is seller opinion. Output: criteria record and unresolved blocker.
Maintain a buyer-agreed Mutual Action Plan. Evidence: shared milestones, dates, buyer and seller owners, dependencies, and decision event. Owner: Action Owner. Failure: the plan is an internal close checklist. Output: updated MAP or requalification decision.
Record a dated next step with a buyer-side owner. Evidence: calendar event, buyer confirmation, or explicit agreed action. Owner: Operator. Failure: next step is “follow up” or only has an internal owner. Output: exact event, date, and owners.
Inspect evidence gaps without converting them to zeros. Evidence: unknown, unverified, negative, and not-applicable states remain distinct. Owner: Decision Owner. Failure: a blank MEDDPICC field is treated as satisfied. Output: gap owner and due date.

Decisions and follow-through

Make one explicit disposition per reviewed deal. Evidence: retain, advance, regress, move period, change category, requalify, close-lost, or escalate. Owner: Decision Owner. Failure: discussion ends without a state change or documented rationale. Output: decision record.
Write CRM corrections during or immediately after review. Evidence: changed field, previous value, actor, and reason. Owner: Operator. Failure: a private meeting note becomes the new source of truth. Output: auditable CRM update.
Carry unresolved actions into the next review. Evidence: owner, date, status, and blocker. Owner: Action Owner. Failure: the same issue is rediscovered weekly. Output: carryover register and escalation.

Decision output: a corrected pipeline, a smaller set of material risks, and owned interventions before the next review.

05 / Method

Checklist 4: Call coaching

Purpose: turn a recorded customer conversation into one observable coaching decision. Conversation intelligence can help retrieve evidence, but the coach remains accountable for context and judgment.

Record and context

Confirm lawful capture and complete context. Evidence: applicable notice/consent, full recording where available, language, participants, stage, and call purpose. Owner: Security/Legal Reviewer and Operator. Failure: a partial transcript is scored as the whole interaction. Output: reviewable call record or exclusion.
Define one coaching objective before scoring. Evidence: behavior tied to the role, stage, and current performance need. Owner: Decision Owner or manager. Failure: the coach grades every possible behavior. Output: one observable target.
Separate transcript fact from AI inference. Evidence: timestamped excerpt for facts and an explicitly labeled inference for interpretation. Owner: Operator. Failure: a generated summary is treated as verbatim buyer evidence. Output: traceable observation.

Conversation controls

Review the talk/listen ratio as a diagnostic, not a grade. Evidence: declared treatment of silence, multiple speakers, demos, and introductions. Owner: Operator. Luck My Sales house target: seller/buyer talk/listen at or below 45/55 for the relevant discovery format. Failure: the ratio decides quality without context. Output: a question or segment to inspect.
Check whether discovery changed the seller’s model. Evidence: buyer problem, impact, current workaround, stakeholders, constraints, and corrected assumptions. Owner: manager. Failure: the seller follows a script without incorporating answers. Output: one better follow-up pattern.
Inspect price objections before discounts. Evidence: the seller clarifies value, scope, comparison, budget process, and trade-offs before changing price. Owner: manager. Failure: an immediate unapproved discount or fabricated commercial term. Output: approved response path and escalation rule.
Verify next steps. Evidence: specific action, date, buyer-side owner, seller-side owner, and dependency. Owner: Action Owner. Failure: “send information” or “circle back” without a decision event. Output: confirmed next step or explicit no-step outcome.

Coaching action

Choose one behavior to retain and one to change. Evidence: timestamps and expected alternative. Owner: manager. Failure: feedback is personality-based or generic. Output: concise coaching note.
Assign a rehearsal and observation window. Evidence: practice scenario, success criterion, next call sample, and review date. Owner: Action Owner. Failure: advice has no opportunity for observed correction. Output: follow-up coaching record.
Do not infer business impact from one call. Evidence: repeated behavior and a comparable outcome measure over a suitable sample. Owner: Data Owner. Failure: correlation is presented as causal improvement. Output: bounded learning claim.

Decision output: one evidence-backed coaching intervention and a scheduled observation, not a decorative score.

**Checked is not verified.** Completion without evidence cannot support the same decision as a traceable control record.

06 / Method

Checklist 5: GTM launch readiness

Purpose: decide whether an outbound or inbound launch has enough evidence, ownership, infrastructure, and rollback capacity to release.

Market and offer

Define the first buyer in context. Evidence: role, company shape, trigger, current workaround, exclusion, and source. Owner: Decision Owner. Failure: the ICP is “B2B companies” or another broad market label. Output: testable ICP statement.
State the problem and value hypothesis. Evidence: observed problem, current cost or constraint, proposed change, and disconfirming signal. Owner: Operator. Failure: the message is a feature list. Output: hypothesis and interview/test plan.
Lock approved pricing boundaries. Evidence: current price source, discount authority, validity date, and exception path. Owner: Decision Owner. Failure: channel content or AI can invent terms. Output: pricing authority record.

Infrastructure and data

Use an isolated, governed sending-domain architecture where appropriate. Evidence: asset inventory, owner, registrar/DNS access, provider, purpose, and rollback. Owner: Data Owner. Failure: experimental outreach can damage an uncontrolled shared domain. Output: approved domain map.
Verify SPF, DKIM, and DMARC for every sending path. Evidence: DNS records, alignment tests, DMARC reports, and provider-specific checks. Owner: Operator. Google’s current sender guidelines distinguish requirements for all and bulk senders, while RFC 9989 defines the current DMARC protocol. Failure: a dashboard badge replaces message-level verification. Output: authentication test record.
Test email validation and hard-bounce handling. Evidence: provider taxonomy, sample validation, suppression behavior, retry policy, and rate denominator. Owner: Data Owner. Luck My Sales house target: hard-bounce rate below 0.5% for the declared attempted-send population. Failure: suppressed addresses disappear from the denominator. Output: preflight result and stop rule.
Route replies to one controlled master inbox and CRM. Evidence: positive, negative, out-of-office, unsubscribe, wrong-person, bounce, and forwarding test cases. Owner: Operator. Failure: replies are split across personal inboxes or cannot update the authoritative record. Output: routing acceptance test.

Release and measurement

Assign all five roles. Evidence: Decision Owner, Operator, Data Owner, Security/Legal Reviewer where applicable, and Action Owner. Failure: a launch task has participants but no accountable decision maker. Output: ownership matrix.
Define leading signal, business outcome, and decision rule. Evidence: baseline, target or comparison, period, eligible population, and stop/continue/adjust rule. Owner: Decision Owner. Failure: activity volume is the only success measure. Output: experiment record.
Run a small acceptance batch. Evidence: representative records, end-to-end tracking, message rendering, reply handling, CRM writes, opt-out, and incident path. Owner: Operator. Failure: launch proceeds from a preview email alone. Output: acceptance report.
Confirm pause and rollback. Evidence: who can stop sending, disable automation, restore routing, export records, and notify affected teams. Owner: Action Owner. Failure: the only rollback is deleting data or waiting for a vendor. Output: tested rollback plan.

Decision output: launch, controlled pilot, hold for evidence, or stop. The decision record names unresolved risks and who accepted them.

07 / Method

How to adapt a checklist without weakening it

Change thresholds and fields when the workflow requires it, but preserve the control logic. Every retained item still needs evidence, owner, failure condition, and output. If a control is not applicable, record why. If evidence is unavailable, mark unknown and decide whether that blocks release.

Use the weekly pipeline review workbook when the pipeline module needs a durable record. Use the Sales AI vendor scorecard when an evaluation advances beyond preflight. The checklist tells you whether the process is ready; the workbook records the decision.

**Evidence states are not scores.** Each state describes what is known and what decision work remains.

08 / Method

Frequently asked questions

Are these checklists free to copy?

Yes. The public page is usable without an account or email gate. A copy function should preserve the labels and method note so evidence states are not reduced to plain checkboxes.

Does every failed item block release?

No. Each module identifies its hard gates. Other failures require a named exception, owner, expiry, and compensating control. A weighted score cannot override a failed legal, security, authority, or critical data gate.

Can AI complete the checklist automatically?

AI can gather candidate evidence and flag missing fields. A human remains accountable for source quality, applicability, exceptions, and release. Automated completion must retain links to the underlying record.

Where is checklist state stored?

In v1, interactive state remains in the current browser session and is not sent to the server or written to cookies or LocalStorage. Users can copy or print their record before closing the page.

Method owner: Anastasiia Krynytska, RevOps Architecture Lead. Reviewed 10 September 2026. Security, privacy, email, finance, and legal controls require review in the actual operating context.

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.