How to Define Entry and Exit Criteria for Every Pipeline Stage

Who this framework is for

This framework is for product, sales, operations, and data teams defining stages that will drive work queues, automation, handoffs, service levels, or reports. It can be used before CRM configuration or to audit an existing workflow.

Contents

1 Scope the process and work item 2 State the purpose of the stage 3 Write testable entry criteria 4 Define allowed work and ownership 5 Write testable exit criteria 6 Add time, exception, and re-entry rules 7 Version the stage contract 8 Test before implementation 9 Illustrative example 10 Copy-ready stage contract 11 Common mistakes 12 What this does not mean 13 Common questions 14 Sources and methodology

1. Scope the process and work item

Start by naming the process. Pipeline is too broad. Examples include outreach preparation, outreach execution, qualification review, signal review, tenant handoff, or human follow-up. Then name the work item: campaign, account, contact, lead, event, route, or task. A stage is valid only within that combination. A lead may be in qualification review while the campaign is outreach in progress and a response task is awaiting owner acceptance. Do not force these into one shared status. Business-process notation distinguishes processes, activities, events, and gateways. OMG publishes BPMN as a standard notation for modeling business processes. Object Management Group, "Business Process Model and Notation, Version 2.0.2" BPMN does not define SellersGPT stages; it is evidence that explicit process scope and flow constructs matter. Complete this header:

• process name and version;

• stage ID and display label;

• work-item type and identity key;

• pursuit and tenant scope;

• stage owner function;

• effective and retirement dates;

• authorizing policy or decision. If the same label has different criteria for different work-item types, create separate contracts.

2. State the purpose of the stage

Write one outcome-oriented sentence: This stage exists to [resolve a defined decision or complete controlled work] before [specific consequence]. Examples:

• Qualification review exists to determine whether one lead satisfies the effective qualification criteria before it is represented as a qualified lead.

• Active-response coordination exists to route an already active lead to an accountable owner while preserving context and keeping ownership-pending work visible.

• Exception review exists to resolve identity, evidence, policy, or processing conflict before contact or state change continues. Then list what the stage does not mean. Qualification review does not imply fit. Active-response coordination does not mean an owner has accepted. Human follow-up does not mean an opportunity exists. These negative definitions prevent stage position from being reported as an outcome. The GAO Green Book links control design to defined objectives, quality information, control activities, and monitoring. GAO, "Standards for Internal Control in the Federal Government" Its federal internal-control scope does not prescribe commercial workflows. The applicable lesson is to anchor a stage in a defined objective and consequence.

3. Write testable entry criteria

An entry criterion must be evaluated from named evidence. Use a predicate, not a vague adjective. Weak: Lead looks qualified. Testable: A lead record exists; identity resolution is Resolved; the current pursuit and qualification-rule versions are known; no applicable hard stop is active; and at least one required criterion needs evaluation. For every entry condition, record: Field Required content Criterion ID Stable identifier Predicate Exact condition that must be true Evidence Accepted source and required fields Unknown handling Wait, review, reject, or not applicable under a rule Hard-gate status Whether failure blocks entry Evaluator Process or role authorized to decide Effective version Rule used at the decision time NASA's systems-engineering guidance describes verification as showing that requirements are met and distinguishes it from validation of intended use. NASA, "5.3 Product Verification" NASA's context is engineered systems, not pipelines. The narrow design lesson is to link a requirement to a defined verification method rather than relying on a label. NASA's example Requirements Verification Matrix uses unique requirement identifiers and identifies the source and verification approach. NASA, "Appendix D: Requirements Verification Matrix" A pipeline stage can use the same discipline without claiming engineering equivalence.

4. Define allowed work and ownership

Once entered, the stage contract controls what may happen. Specify:

• authoritative current owner and acceptance rule;

• permitted automated and human actions;

• prohibited actions;

• required context and evidence access;

• tasks created on entry;

• service clock and pause conditions;

• escalation and fallback;

• events that immediately cancel work;

• visibility and edit permissions. For qualification review, permitted work may include verifying identity and criteria evidence. Contacting a new person may be prohibited. For active-response coordination, ordinary prospecting automation should already be paused, while context assembly, owner routing, acceptance reminders, and escalation may be allowed. For stopped, no commercial contact task can be created; only suppression administration or approved review is permitted. One current owner prevents silent diffusion. Contributors can perform sub-tasks, but the stage owner remains accountable until a successor accepts. If an automated process owns a stage, name the human or operations queue responsible for exceptions and monitoring.

5. Write testable exit criteria

Exit is not synonymous with work completed. Define every allowed outcome:

• success path;

• negative or disqualifying path;

• stop or suppression path;

• exception path;

• expiry path;

• merge or duplicate path;

• cancellation due to scope change;

• rollback or correction path. For each exit, specify the resulting stage or terminal state, lifecycle consequence, event, tasks created or canceled, and required evidence. The Federal Acquisition Regulation's Part 46 provides a public-sector example of explicit quality requirements, inspection, evidence, and acceptance decisions. FAR Part 46, "Quality Assurance" It does not apply to commercial pipeline stages. It illustrates that acceptance, conditional acceptance, and nonconformance require defined requirements and authority rather than informal completion. Use exit predicates such as: Exit to qualified only when every applicable criterion is Satisfied under rule Q-7, all hard exclusions are False, the decision event is stored, and any mandatory review is approved. Exit to remains lead when at least one material criterion is Unknown and the review window remains open; create a scoped evidence task. Exit to stopped immediately when an applicable suppression event is effective; cancel conflicting tasks regardless of other criteria.

6. Add time, exception, and re-entry rules

Every non-terminal stage needs a time boundary. Define:

• clock start and timezone;

• calendar or business-time basis;

• pauses and resumptions;

• warning and breach thresholds;

• escalation owner;

• expiry outcome;

• maximum stage age;

• data-freshness review triggered by delay. Time passage can cause escalation or expiry, but it does not prove buyer progress. A lead does not become qualified after seven days. An owner route does not become accepted because the assignee was silent. Define exception reasons, including ambiguous identity, conflicting evidence, unavailable dependency, out-of-order event, duplicate processing, policy uncertainty, inaccessible payload, and system failure. Each exception needs an owner, safe allowed actions, deadline, and terminal outcome. Re-entry needs an explicit trigger. A stopped contact cannot re-enter because a record was re-imported. A closed pursuit can re-enter only under a new approved scope, with suppression and historical evidence inherited. A corrected processing defect can re-enter at the stage justified by original effective time and rule.

7. Version the stage contract

Never silently edit criteria that already classified work. Record:

• semantic version or immutable rule ID;

• change description and reason;

• approving owner;

• effective date and time;

• affected in-flight items;

• migration, grandfathering, or re-evaluation rule;

• rollback condition;

• retirement date. Events should reference the stage-contract version used. The CloudEvents specification provides common event-context attributes such as source, type, subject, ID, and time. CloudEvents Specification It is a technical event standard, not a stage-rule system. It supports the importance of stable context when process events cross services. If a rule becomes stricter, decide whether existing items remain under the old version, re-evaluate, drain, or stop. Do not mix the two populations in one report without a rule-version dimension.

8. Test before implementation

Create test cases before configuring automation: 1 normal entry with complete evidence; 2 entry with one required Unknown; 3 hard-gate failure despite positive evidence; 4 duplicate trigger delivered twice; 5 late event arriving after stage exit; 6 conflicting evidence from two sources; 7 owner rejects or ignores assignment; 8 time boundary expires; 9 suppression arrives while work is queued; 10 rule version changes with items in flight; 11 state reversal after new evidence; 12 merge and split of subject records. Store expected stage, lifecycle state, tasks, events, owner, and audit outcome. NIST's log-management guide discusses policy and process for generating, storing, accessing, and disposing of log data. NIST SP 800-92 It does not define test evidence for GTM, but it supports retaining reviewable execution records. Release only when the test suite demonstrates both permitted transitions and blocked actions. A happy-path demo is insufficient.

9. Illustrative example

Illustrative example - explicitly fictional. BlueHearth Motion designs an Active Response Coordination stage for already-active leads whose required action still needs an accepted owner. Its entry contract requires five predicates: 1 current lead state is active lead with one verified required action; 2 a human-action reason exists; 3 route context version is complete; 4 target owner is eligible; 5 no suppression or company-stop gate is active. During a fictional test of 20 route attempts, 13 satisfy all five predicates. Three lack complete context, two have an ineligible owner, one is a duplicate, and one has a company stop. The partition is 13 + 3 + 2 + 1 + 1 = 20. Of 13 admitted items, 10 are accepted before the service deadline, two are rejected with a reason and enter the routing exception path, and one expires and escalates. The partition is 10 + 2 + 1 = 13. Only the ten accepted routes exit to Human Owned; the other three records remain active with visible ownership exceptions. None of the rejected, expired, duplicate, or stopped routes is counted as accepted. These fictional rates are routing-control test results, not lead or sales benchmarks.

10. Copy-ready stage contract

Use this structure: Contract section Entry Process / stage / work item Purpose and non-meaning Scope and effective version Entry predicates and evidence Hard gates and precedence Unknown and conflict handling Owner, acceptance, and fallback Allowed and prohibited actions Tasks on entry Service clock and pause rules Exit predicates and outcomes Events and tasks on each exit Exception and expiry routes Re-entry and reversal rules Reporting dimensions Test cases and approval

11. Common mistakes

• Defining stages by intuition rather than predicates.

• Mixing account, campaign, lead, event, and task stages.

• Using lifecycle state as a work queue.

• Treating Unknown as a failed or passed criterion without a rule.

• Writing only a success exit.

• Allowing time expiry to imply buyer progress.

• Changing criteria without versioning in-flight work.

• Testing only normal entries.

• Leaving owner rejection and fallback undefined.

• Letting a stop event wait behind a stage timer.

12. What this does not mean

Stage contracts do not make organizational buying linear or eliminate human judgment. They do not require every process to have many stages. A smaller number of precise stages is usually more useful than a large taxonomy with weak meaning. The framework does not choose markets, define ICPs, map stakeholder roles, set lead billing, or govern AI. It defines how approved rules become controlled workflow. The cited engineering and acquisition sources are limited analogies, not claims that B2B outreach is a government acceptance process.

13. Common questions

Should entry criteria and exit criteria be opposites? Not necessarily. Entry defines what must be true to begin controlled work; exit defines every acceptable outcome of that work, including success, negative, exception, expiry, merge, and stop. Can a person manually override a stage gate? Only if the contract names the authorized role, permitted conditions, required reason and evidence, resulting tasks, and audit event. Suppression and legal hard gates should not have ordinary commercial overrides. How many stages should a pipeline have? Use only as many as needed to create different ownership, allowed work, evidence, time, or outcome rules. If two stages have identical contracts, consider combining them. What happens when criteria change? Publish a new version and define treatment of in-flight work: continue, re-evaluate, drain, migrate, or stop. Report cohorts by the version that made each decision.

14. Sources and methodology

The stage-contract model, entry and exit fields, exception taxonomy, and test suite are SellersGPT editorial tools. Sources support limited principles about process representation, verification, traceability, controls, acceptance, logs, and event context. They do not prescribe commercial pipeline stages. 1 PP07-OMG-BPMN - Object Management Group, "Business Process Model and Notation, Version 2.0.2." https://www.omg.org/spec/BPMN/2.0.2/PDF Accessed August 25, 2026. 2 PP07-NASA-VERIFY - NASA, "5.3 Product Verification." https://www.nasa.gov/reference/5-3-product-verification/ Accessed August 25, 2026. 3 PP07-NASA-MATRIX - NASA, "Appendix D: Requirements Verification Matrix." https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/ Accessed August 25, 2026. 4 PP07-GAO-GREENBOOK - U.S. Government Accountability Office, "Standards for Internal Control in the Federal Government." https://www.gao.gov/products/gao-14-704g Accessed August 25, 2026. 5 PP07-FAR-QUALITY - U.S. Federal Acquisition Regulation, "Part 46 - Quality Assurance." https://www.acquisition.gov/far/part-46 Accessed August 25, 2026. 6 PP07-NIST-LOGS - National Institute of Standards and Technology, SP 800-92, "Guide to Computer Security Log Management." https://csrc.nist.gov/pubs/sp/800/92/final Accessed August 25, 2026. 7 PP07-CLOUDEVENTS - Cloud Native Computing Foundation, "CloudEvents Specification, Version 1.0.2." https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md Accessed August 25, 2026.