Commit vs best case: what evidence each category needs

01

What the forecast categories in a CRM say

In Microsoft's definitions for Dynamics 365, Committed means the customer has made a verbal or contractual commitment, and the seller is mainly waiting on paperwork or final approvals; Best case is a deal where quotes or substantive conversations have taken place, but there is no commitment yet.

HubSpot can move a deal to a new forecast category automatically when the deal changes stage, which makes the category only as good as the stage's exit criteria.

02

Commit, best case and pipeline as evidence rules

Write each category as the evidence it needs for each of the eight MEDDPICC elements (MEDDICC with the paper process added). The table uses the four evidence statuses of the MEDDICC scorecard: Not asked, Assumed, Relayed (your contact passed on someone else's account) and Confirmed (confirmed by someone who can confirm it, through their own words, a document or an action); some cells also ask for an action or an outcome. It is a starting standard: a short sales cycle may ask less of best case, and a long one more.

Put a deal in the highest category whose column it meets on every row. If it misses a commit requirement, use best case only if it meets every best-case requirement. Otherwise, keep it in pipeline when it meets that column and record the gaps. For what counts as a confirmed answer on each element, see MEDDICC questions and what counts as an answer.

03

Two rules for the hard cases

An economic buyer who has not confirmed is a risk flag on the deal, not a verdict on it. Flag the risk and keep the deal out of commit until the economic buyer has confirmed what they can approve and the outcome they require. Use best case only if the buyer is named, their authority has been relayed and the other best-case requirements are met. Otherwise, use pipeline if it meets that column. Dropping the deal hides a real opportunity, and committing it hides the risk.

Judge evidence by its strength, not by how many fields have something in them. The economic buyer confirming in their own words what they can approve and the outcome they require can count for more than several relayed signals from a contact who likes you. A deal with all eight elements marked Assumed has eight entries but no confirmed answers. Check it against the pipeline column, including whether there is a potential champion, and record what still needs to be learned.

The close date needs its own evidence. To use the commit standard above, ask each review owner to confirm their step and date in the paper process. GitLab's handbook for enterprise sales managers sets a timing rule: entering the second month of a quarter, every opportunity forecast for that quarter should be in either Best Case or Commit, and if it is not, its close date should be pushed out.

04

A one-page deal review template

The template records the evidence behind the category the seller proposes, and the questions to ask behind each line are the deal review questions on the opportunity qualification page. The seller fills it in before the review, and the review spends its time on the lines that would move the deal up or down a category.

Deal, amount, close date and the category the seller proposes.

For each element: the evidence in one line, its status (Not asked, Assumed, Relayed or Confirmed), who confirmed it and on what date.

Each element that falls short of the next category's column in the table above.

For each of those, the customer step that would create the evidence, with an owner and a date.

Risk flags, written as facts about the deal, such as "economic buyer not confirmed" or "security review date not confirmed by its owner".

The category after the review, and the evidence that would move it.

05

A pipeline review agenda that discusses deals, not sellers

In its best practices for forecasting and pipeline reviews, GitLab's public handbook for enterprise area sales managers says: "It's not a performance review."

For the weekly review, an agenda built on the evidence standard has five items:

1. Category changes since last week, each with the evidence that moved the deal.

2. Commit deals with any element below the commit column.

3. Best case deals: the gaps to commit and the customer steps that would resolve them.

4. Deals forecast for this quarter that are still in pipeline: the evidence for their dates and any date that needs to change.

5. Actions, each with an owner and a date.

Describe the deal, never the seller. "No confirmed date for the security review" says what the deal needs. "You haven't pushed procurement" says something about the person, and next week's review will get a better story rather than better evidence. A single gap is a fact about one deal. When the same gap comes back across several deals over several weeks, it is a pattern, and it belongs in a one-to-one rather than in front of the team.

When deal reviews stay at status level, I can start by listening in on one of your pipeline reviews.