Sales · Free implementation template

Lead Qualification Scorecard

Create a transparent qualification model that combines fit, intent, timing, and human review instead of opaque AI scoring.

Introduction

What the Lead Qualification Scorecard is for.

Create a transparent qualification model that combines fit, intent, timing, and human review instead of opaque AI scoring.

A completed sales template is a specification for CRM behaviour: which records are authoritative, which stage transitions matter, who owns the next action, and what may run without a human. This one covers fit, intent, decision, audit, and it is written for sales teams, marketing teams, founder-led sales. Each section is a decision that has to exist before the workflow can be built or automated — the prompts are there to force the decision, not to be filled in for their own sake.

A completed template is also a structured brief. ARIA can read it as the objective, the systems involved, and the constraints that apply, which is what turns the specification into something that runs rather than something that gets filed.

Category
Sales
Sections
4
Format
Markdown, no signup
Best for
Sales teams, Marketing teams, Founder-led sales

The problem

Specifications fail on the decisions nobody wrote down.

Sales process documentation usually describes what the team intends to do rather than what the system will enforce. The gap shows up as pipeline that cannot be forecast: stages mean different things to different reps, and the reporting built on top inherits the ambiguity.

The expensive part is not writing the process down. It is that every automation, dashboard, and handoff built afterwards encodes whichever interpretation the implementer happened to hold, and those interpretations only surface when the numbers disagree.

Filling this in first turns the disagreement into a conversation between the people who own the outcome, before it becomes a defect distributed across the CRM.

You're likely here because

  • Sales and marketing disagree about lead quality
  • Qualified leads are worked inconsistently
  • Nobody can say which qualification input actually predicts conversion

How it works

From a blank Lead Qualification Scorecard to a running workflow.

Each stage is a decision that has to be made once. Making them in this order is what keeps the later ones answerable — you cannot set an automation boundary before you know who owns the record.

01Fix the stage definitions02Name the record owner03Set the automation boundary04Declare field authority05Attach the measurement

Step 01

Fix the stage definitions

Each stage gets an entry condition and an exit condition that can be evaluated from data rather than from judgement. Stages that cannot be evaluated from a record are not stages; they are opinions.

Step 02

Name the record owner

Every record and every exception gets one accountable owner and a named backup. Shared ownership is the most common cause of a stalled pipeline workflow.

Step 03

Set the automation boundary

Mark which actions may run automatically, which require approval, and the numeric thresholds that separate them. "Significant deals need review" is not a rule a runtime can apply.

Step 04

Declare field authority

Where the CRM and another system both hold a field, record which one wins. This is what keeps an automated enrichment from overwriting an amount or a close date.

Step 05

Attach the measurement

Each metric names the population it is computed over, so conversion and cycle time stay comparable once the process changes.

The template

Every section, with the prompts that force the decision.

Section 01

Fit

Company type
Size
Industry
Use case

Section 02

Intent

Inbound action
Problem urgency
Requested next step
Engagement evidence

Section 03

Decision

Qualified
Nurture
Disqualify
Human review

Section 04

Audit

Reason code
Reviewer
Override reason
Outcome

After it is filled in

What the completed specification is actually consumed by.

Filling in the Lead Qualification Scorecard produces an artifact, and an artifact on its own changes nothing. What matters is what consumes it afterwards.

Handed to the runtime, a completed sales specification stops being a document and starts being configuration. The authoritative record it names becomes the one the workflow reads; the stage transitions it defines become the events that trigger action; the ownership column becomes the routing rule. None of this requires the CRM to change — the system of record stays authoritative, and what the specification governs is the behaviour around it.

The part worth checking afterwards is the boundary drawn between automatic and approved. A specification that marks everything as requiring approval produces a workflow nobody uses; one that marks nothing produces a workflow nobody trusts. Most teams get this wrong in the same direction on the first pass and correct it once they have watched a week of real stage transitions.

Implementation path

How to actually fill it in.

  1. 01

    Work through the template with the rep, the manager, and whoever owns the CRM, in the same room. Disagreement found here costs a conversation; found later it costs a migration.

  2. 02

    Write the stage exit conditions as checks against fields that already exist, and add the missing fields before automating anything.

  3. 03

    Record the numeric approval thresholds — discount, amount, term — as values rather than adjectives.

  4. 04

    Pilot the workflow against a single segment with real records before rolling it out to the full pipeline.

  5. 05

    Re-run the measurement section against the same population after the change, so improvement is attributable rather than asserted.

Controls this specification sets

Controls that matter.

01

Control 01

Automated writes respect the existing record owner rather than reassigning as a side effect.

02

Control 02

Matching runs before any create, and an ambiguous match raises an exception instead of producing a duplicate.

03

Control 03

Discount, pricing, and contract-term changes stay behind explicit human approval.

04

Control 04

Every automated CRM write records the event that caused it.

Worked examples

When teams reach for this one.

Resolving a lead-quality dispute

The disagreement is almost always an undefined threshold. Writing the criteria down converts an argument into a testable rule.

Before automating routing

Routing built on an unwritten definition encodes one person’s interpretation across every future lead.

Reviewing conversion by criterion

Scoring inputs against downstream conversion usually shows one or two carry the signal and the rest add noise.

Limitations

What this template does not do.

  • Scores are directional; they rank leads, they do not predict outcomes.
  • Weightings need recalibrating against real conversion data before they are trustworthy.
  • A scorecard built on self-reported form data inherits whatever that data gets wrong.
  • It does not address lead volume or source quality, which usually matter more than scoring.

FAQ

Questions about the Lead Qualification Scorecard.

Who should fill in the Lead Qualification Scorecard?

The people who own the outcome, together. This template is written for sales teams, marketing teams, founder-led sales, and the value comes from surfacing disagreement between them rather than from one person completing it alone.

How long does it take?

A focused session, usually one to two hours for a first pass. Sections that take much longer are normally pointing at a real disagreement, which is the template doing its job rather than failing.

Is it free, and is there a signup?

Free, with no gate. The Markdown download link at the top of this page returns the full template immediately.

What happens after it is filled in?

The completed template becomes the specification the build works from. You can hand it to ARIA to resolve into an objective and an execution path, hand it to an internal team, or use it to brief a vendor — the artifact is the same in each case.

Does this replace the tooling?

No. It specifies what the tooling has to do. Sales tools differ in how much of this they can enforce, which is itself useful information when you are comparing them.

How often should it be revisited?

When the process it describes changes, and on a scheduled review otherwise. A specification that no longer matches what runs is worse than none, because people still trust it.

Start with ARIA

Hand the brief to ARIA.

A completed template is a structured brief. Tell ARIA the objective and it resolves the systems involved and the execution path — so the specification becomes a running workflow, not another document.

  • ARIA acts only through the systems and permissions you connect.
  • Connections use scoped credentials you can change or revoke.
  • Actions are recorded, and consequential ones can require approval.

Goes to UbiGrowth, with the page you asked from attached. We do not sell or share it. Prefer to talk? Call 972-823-1294.

Start here

Fill it in, then hand it to ARIA.

A completed template is a structured brief. ARIA can resolve it into the objective, the systems involved, and the execution path — so the specification becomes a running workflow rather than another document.