meddicc-qualification
Skill0 starsChanged 12 days agoMITView on GitHub
Qualifies a live B2B software opportunity with MEDDICC (or MEDDPICC) by treating each element as an evidence claim, preparing the customer questions that can confirm it, and recording who confirmed what. Use before a qualification call, after one, or before a deal review or forecast call, including when the user wants to check Metrics, Decision Criteria or the Paper Process in depth.
In this repository5 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Put five questions to each element.
- Distinctive: line 20
Before the call, mark elements where missing evidence could change the customer's decision, and name the role that can confirm each.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
MEDDICC qualification
MEDDICC is a widely used third-party framework. Here every element is an evidence claim: an answer counts only for the point its source can confirm. Fields filled in are not a qualified opportunity.
Ask for these inputs
- Customer, product, stage, expected close date.
- The team's view of each element, and its source.
- Customer documents: requirements, criteria, approval procedures, reports, supplier rules.
Steps
- Put five questions to each element. What do we know? How do we know it? Who confirmed it? What remains an assumption? Which conversation or action could create the missing evidence?
- Accept three forms of "how we know": the person's own words to you, a document of theirs or an action, such as an introduction made.
- Before the call, mark elements where missing evidence could change the customer's decision, and name the role that can confirm each. Record relayed accounts as such.
- Prepare questions from this table:
| Element | Ask the customer | Counts as evidence | Who can confirm |
| Identify Pain | What happens if this stays as it is? By when must it change, and who feels the consequence? | Their words: problem and consequence in cost, revenue or risk | Who has the problem; who is in charge of fixing it |
| Metrics | Can you show today's baseline? What result would justify the change? | Baseline in their report; target and outcome in their words | Owner of the measure; economic buyer |
| Economic Buyer | Who can approve this? Then: what can you authorize, whose agreement do you need, what outcome would justify it? | Their words on authority for this purchase and required outcome | The economic buyer |
| Decision Criteria | How will you compare options? Can we review the written criteria, priorities and who agreed them? | Criteria document with priorities, confirmed by stakeholders | Those setting and assessing requirements |
| Decision Process | How will you evaluate and approve? Who owns each step, and when? | Steps, owners, dates, what completes each | Step owners |
| Paper Process | Who owns each review before signature, how long does each take, who signs? | Each review, owner, duration, signer | Procurement, legal, security; the signer |
| Champion | Will you introduce us to the person who can approve this? What will you do internally to help the decision? | An action: introduction made or internal step taken | The contact and the people involved |
| Competition | What else are you considering, including changing nothing or building it yourselves? How do you see each? | Alternatives they name and how they see each | Those scoring options; economic buyer |
- Apply the element rules:
- Pain counts when the customer says it is a problem for them. Inferences from their tools or industry stay assumptions. Ask who else would describe it so.
- Economic Buyer: the last comparable purchase is a starting point and does not confirm current authority. Record approval role and required outcome as separate answers.
- Champion: call them a potential champion until they act; you may be dealing with a coach. meddicc.com notes that reluctance to introduce you to the economic buyer may signal they are no true champion. In a deal review, ask what they have done since the last call.
- Decision Process: more meetings do not show progress. Ask which agreed step the latest demo completed, and whether a purchase of this size has happened before.
- Metrics: write each line as a chain. Product number, the change in the customer's work, and the cost, revenue or risk that change moves. Technical evaluators prove the product number; the economic buyer funds the business figure. If a number is missing, agree with its owner how to establish the baseline and what the proof must show.
- Decision Criteria: record five parts. Pass or fail requirements and whether you meet them. Weights, or order of importance. Minimum scores and where they apply. Demonstration: scored or not, whose scenarios and data, who scores. Price: how cost affects the comparison, with weight and formula if used. A confirmed "no minimum score" is still evidence. Record any confirmed requirement that excludes your offer.
- Paper Process: describe how the product would be used here (data, system connections, sign-on, payments, AI features, users, annual cost) and ask which reviews that triggers. For each: who runs it, what it needs from you, what it must finish before (legal review, purchase order, pilot, system access), how long it takes from when, and whether an earlier approval exists. Ask who signs. Mark dates unconfirmed until the review owner confirms, and put each review into the mutual action plan.
Output
| Element | What we know | How we know | Who confirmed, date | Open assumption | Next question, to whom |
Example entry: "The IT manager named the finance director as the economic buyer. Approval authority for this purchase is unconfirmed. Next: ask the finance director what they can approve and whose agreement they need."
Checks
- A field with no named source is an assumption.
- A Metrics line that stops at the product number goes back: what does it do to cost, revenue or risk, and who at the customer said so?
- Topic lists without trade-offs are not qualified criteria.
- An unmapped paper process makes the signature date an assumption.
Based on: MEDDICC template: questions and what counts as an answer, MEDDICC Metrics examples: product results and business value, MEDDICC decision criteria: examples written by buyers and MEDDPICC paper process: examples from buyers' supplier rules
A browser version of the same check, for people without an agent: MEDDICC scorecard.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.