BANT vs MEDDIC vs custom criteria in production

EchoStack evaluations are manifest-driven: you declare frameworks or typed detectors once; every webhook, form, and n8n path uses the same rules. This guide is for RevOps and platform engineers picking BANT, MEDDIC, SPICED, CHAMP, or custom detectors before you wire production traffic.

Outcome

You can defend a single answer to “what does qualified mean here?” — and every channel returns the same status semantics for the same field presence.

Quick decision tree

Inbound SMB / self-serve motion?
  └─ Yes → Start with BANT (budget, authority, need, timeline)

Enterprise / multi-stakeholder / complex procurement?
  └─ Yes → MEDDIC or SPICED (metrics, economic buyer, decision process)

Non-standard signals (partner type, compliance tier, product line)?
  └─ Yes → template: "custom" with typed custom_detectors

Same company, multiple motions (PLG + sales-assist)?
  └─ Separate evaluation_id per motion — do not reuse one manifest

Framework packs (lead_qualification)

Create an evaluation with template: "lead_qualification" and set framework:

The platform applies the detector pack for that framework. You do not maintain parallel prompts in Zapier.

See Eval API quickstart for the create payload.

What you get back (all frameworks)

Same response contract:

• status — derived deterministically from which required fields were found (not a 0–100 score)
• extracted_fields — structured signals
• missing_fields — gaps for PARTIAL routing
• next_action / next_instruction — when requested

Procedural fit: Two runs with the same manifest and the same field presence should yield the same status. That is intentional — it is how you avoid “looks qualified in CRM but failed BANT on audit.”

BANT in production

Use when:

• Demo request and contact forms include budget/timeline (even optional)
• Webhook → evaluate → assign AE (webhook guide)

Watchouts:

• Forms that omit budget always → chronic PARTIAL (fix the form or accept nurture-only routing)
• Branching only on “company size > 50” while ignoring status → procedural drift

MEDDIC / SPICED in production

Use when:

• Post-call transcripts include economic buyer and decision process (post-call guide)
• Reps already trained on MEDDIC; you want CRM stages aligned to extracted fields

Watchouts:

• Short webhooks without call context → many PARTIAL results (expected — route to discovery call, not disqualify)
• Expecting numeric MEDDIC “scores” — EchoStack returns field presence and status, not percentages

When to use template: "custom"

Use custom detectors when framework packs do not match your language:

• Partner referrals (classification: partner | customer | unknown)
• Regulatory tier (presence: pci_scope_mentioned)
• Product-line fit (classification with fixed categories)

Rules from the quickstart still apply:

• Every detector needs examples (smoke-tested at create time)
• classification requires categories; negatives use a catch-all category, not non_examples
• presence supports non_examples

Changing detectors means creating a new evaluation (or versioning your internal config) — do not edit criteria in a Zapier prompt on the side.

One criteria definition, many channels

Same evaluation_id + esk_… everywhere — “qualified” does not mean one thing in HubSpot and another in n8n.

Anti-patterns

Changing framework later

1. Create a new evaluation with the new framework or custom detectors.
2. Point webhooks/n8n at the new evaluation_id.
3. Compare Recent evaluations for a week before cutting over CRM branches.
4. Keep the old evaluation read-only for audit if compliance asks.

Related guides

• Eval API quickstart
• EchoStack vs Zapier for qualification
• Inbound lead qualification API

Verify before go-live

• Framework matches motion (tree above)
• Required form/call fields actually appear in webhook content
• Automation uses status for owner assignment
• PARTIAL has a defined nurture path
• Team agrees “qualified” = manifest required fields, not rep opinion