SEE THE WORK BEFORE YOU SIGN UP
Another report?
Make this one earn its keep.
Pick a sales problem. Read the next move, the working exercise and the limits. This is the same report engine you will use with your own context.
CONVERSION / EXAMPLE REPORT
Are demos failing, or are we sending the wrong deals into them?
Locate the problem before rewriting the process. Use the working session and proposed tracker to decide what to change.
01Your decision brief
Locate the problem before rewriting the process.
Do this next: Compare recent slipped or stuck deals with deals that progressed. Record where the issue first appeared, the last confirmed buyer action and any close-date changes. Group similar cases before choosing a fix.
Suggested owner: The current owner of that sales stage, with whoever maintains CRM reporting. Confirm the person and their capacity; nobody has accepted work through this report.
Do not raise a conversion target or rebuild every stage from a headline rate.
Basis: GTM Architect diagnostic judgement. This is a proposed next move, not a finding that your process caused the problem.
Why this fits the answers you gave
- Your answer does not establish one specific affected step. Keep the description as context and use deal records to locate the pattern; do not invent a stage name.
- Start with the deal observations you supplied, shown in full under your inputs. Add contrasting outcomes before treating them as a pattern.
- Keep the comparison within your reported mid-market customer group before generalising to a different buying process.
- Your supplied ACV is GBP 20,000. Use comparable deal scope when choosing cases; that amount does not prescribe a universal process or target.
- Your supplied cycle is 60 days. Use it with actual stage history to choose the follow-up window; still-open deals are not automatically failures.
- You reported inconsistent use of stage rules. Have reviewers apply the existing wording to the same cases before rewriting it.
02Run this working session
Find out whether these deals have the same problem
Keep customer names and sensitive details in your approved company systems. Use opportunity IDs in the working record.
| Your starting brief | Use or confirm this |
|---|---|
| Location description | discovery to demo |
| Working scope | the point identified from the deal records |
| Question to use | Where does the issue appear, and do the same buyer dependencies or prediction errors recur? |
| Requested outcome | Decide whether to change demo entry criteria or investigate the lead mix. |
| Suggested owner | The current owner of that sales stage, with whoever maintains CRM reporting. Assign an actual person; no acceptance is recorded. |
Step 1: Reconstruct what happened
For each comparable deal, record its actual stage history, buyer actions, original expected close date and subsequent changes. Keep missing information visible.
Write down: A short timeline per deal, using records rather than retrospective guesses.
Step 2: Separate different problems
Compare deals that progressed with those that slipped or stalled. Group similar buying situations. Distinguish a buyer waiting on a dependency from a seller predicting an unsupported close date; both can occur together.
Write down: Groups of comparable cases, recurring issues and exceptions. Do not force everything into one stage.
Step 3: Choose the smallest justified test
If a pattern appears, choose one affected group and test a specific change. If the causes differ, use separate tests. If the records reveal no pattern, improve observation instead of redesigning the process.
Write down: A focused test with an owner and review point, or a clear reason to gather more observations.
Bring back: A deal-by-deal comparison, any recurring pattern, and one justified next test or an explicit unresolved question.
| Capture for each case | Record from the deal, not from memory |
|---|---|
| Deal, group and stage-entry date | Record the answer, its date and supporting record. Leave unknowns visible. |
| Buyer condition on entry | Record the answer, its date and supporting record. Leave unknowns visible. |
| Next-stage date or loss date | Record the answer, its date and supporting record. Leave unknowns visible. |
| Open status and observation cut-off | Record the answer, its date and supporting record. Leave unknowns visible. |
03A rollout you can control
Every row below is proposed. Completion, assignment and business outcomes have not been recorded. Use the editable Word copy to assign people and record what actually happens.
| Proposed action | Owner, checkpoint and output |
|---|---|
| Prepare the comparison Compare recent slipped or stuck deals with deals that progressed. Record where the issue first appeared, the last confirmed buyer action and any close-date changes. Group similar cases before choosing a fix. | Suggested owner: The current owner of that sales stage, with whoever maintains CRM reporting Checkpoint: Before changing the live process Output: A deal-by-deal comparison, any recurring pattern, and one justified next test or an explicit unresolved question. Status: proposed; actual progress not recorded. |
| Try one justified change Pilot one clarified entry or exit condition only if the case comparison supports it. Keep the old approach available if valid deals are excluded. | Suggested owner: The current owner of that sales stage, with whoever maintains CRM reporting Checkpoint: Only after the working session identifies a change worth testing Output: Agreed scope, named owner, observation window and unacceptable downside. Status: proposed; actual progress not recorded. |
| Keep, revise or stop Pilot one change if comparable deals expose the same mismatch. A better conversion rate is worth investigating; it doesn't prove your new rule caused it. | Suggested owner: The current owner of that sales stage, with whoever maintains CRM reporting Checkpoint: When the agreed event has had time to occur; use actual deal history Output: Decision, supporting deal observations, unresolved limits and next owner. Status: proposed; actual progress not recorded. |
The decision to make: Is there a recurring problem worth testing, or are these different situations that need different responses?
| Decision record | Complete after reviewing actual observations |
|---|---|
| Decision and reason | Keep / pilot / revise / stop, with supporting deal records. |
| Scope and accountability | Exact change, affected deals and teams, named person and review date. |
| What happened | Actual observations and any downside. Do not record a proposed benefit as a result. |
04Judge the change without kidding yourself
These are suggested measures, not external benchmarks or numerical targets. Record the current observation before deciding what improvement would be useful.
| Measure | How to record it |
|---|---|
| Stage progression | Deals reaching the defined next stage by the cut-off, divided by all deals that entered the stage in the selected period. Show the period, count and cut-off. |
| Still open or lost | Show open and lost deals separately. Don't count unfinished deals as losses just to make the maths look tidy. |
| Evidence on entry | For each deal, mark the chosen buyer condition as confirmed, contradicted or unknown. |
Keep the comparison fair: Keep the stage definition, entry period and follow-up window the same. Separate customer groups or deal types that buy differently.
You reported a 60-day sales cycle. Give the relevant event time to happen. An unfinished cycle cannot establish a completed sales result.
Show case counts, selection rules, dates and missing data. If there are too few comparable cases, describe them individually instead of presenting a convincing-looking percentage.
Continue only if: A recurring issue and a specific, testable change are supported by the deal records.
Stop or revise if: No common pattern, incomparable cases or missing records: improve observation rather than force a process redesign.
Include the downside: extra work, valid deals excluded or new confusion. Clearer records do not prove a revenue gain.
05Your inputs and the open questions
These are your answers, retained as supplied. GTMA has not checked your CRM or independently verified them.
| Context | Your answer |
|---|---|
| Company | Fictional SaaS team |
| Question | Are demos failing, or are we sending the wrong deals into them? |
| Main concern | Conversion between sales stages |
| Where it happens — your description | discovery to demo |
| Stage criteria | inconsistent |
| Recent deal observations | Fictional examples: inbound trials reach demos quickly, while outbound prospects often attend before agreeing there is a problem worth solving. The team combines both in one conversion figure. |
| Desired outcome | Decide whether to change demo entry criteria or investigate the lead mix. |
| Customer segment | mid-market |
| Sales motion | sales-led |
| Average contract value | GBP 20,000 |
| Sales cycle | 60 days |
06The method and its limits
Possibility to examine: Deals may be entering the stage without the buyer evidence needed to move forward. That's a possibility to test, not a cause we've established.
Another explanation to keep in view: Deal mix, buyer need, deal size or time allowed to progress could explain the conversion gap.
Test 1: Compare before choosing a stage to change
The answers do not establish one common point of failure. Different delays or prediction errors may need different responses.
- Start with your examples, then add contrasting outcomes. A handful of chosen stories doesn't represent the whole pipeline.
- Record stage history, buyer actions, original close-date predictions and subsequent changes.
- Group similar cases; keep distinct dependencies and missing records separate.
- Choose a focused test only if the comparison reveals a recurring issue.
- Check that the test addresses the outcome you asked for. Wanting an improvement doesn't mean this change will deliver it.
- Use your reported 60-day sales cycle to choose a fair observation window. Still-open deals are not automatically losses.
Change it if: A recurring issue and a specific, testable change are supported by the deal records.
Stop or revise if: No common pattern, incomparable cases or missing records: improve observation rather than force a process redesign.
07Evidence and how we use it
These are attributed source findings, followed by our interpretation where the connection is explicit. They do not establish this company’s cause or prove that the proposed exercise works.
[1] This company needed a lead scoring model that was not static and allowed marketing and sales teams to determine the order of attention they should give to leads based on their probability of conversion, since there was evidence that sales representatives, as in other B2B organizations, did not have information at an early stage to determine the probability of a lead and often focused on qualifying leads without an established order.
Frontiers in Artificial Intelligence | The relevance of lead prioritization: a B2B lead scoring model based on machine learning | Published: 2025-03-07 | Evidence level C | PRACTITIONER_OPINION
Authors: Laura González-Flores, Jessica Rubiano-Moreno, Guillermo Sosa-Gómez.
Claim context: not recorded. Location: first character: 4300; last character: 6474.
Claim context not recorded: population, study or observation period, methodology, sample size. Do not assume these details or that the finding applies to this company.
Scope: Attributed source finding. It does not prove that the proposed test will work for this company.
Citation ea596196-547d-4b00-a7a0-c887f784145e. Source version 46288fcf-b6d2-4d7b-b702-db6133782349.
Our interpretation, not a source conclusion: This company case separates deciding whether a lead is worth pursuing from deciding which lead deserves attention next. In your review, check whether those are separate, explicit decisions. It does not establish that a scoring model will improve your conversion, or that this company’s approach fits yours.
[2] If the details on the opportunity do not meet our Sales Accepted Opportunity criteria, the SAE or AE should move the opportunity to an 9-Unqualified stage (this is the only time an opportunity can move into 9-Unqualified stage): SAE / AE should provide a reason as to why the opportunity is deemed unqualified for coaching purposes.
GitLab | Commercial Sales Opportunity Stages handbook page | Published: date not recorded | Evidence level C | PRACTITIONER_OPINION
Source: https://handbook.gitlab.com/handbook/sales/commercial/comm-sales-opp-stages/
Reuse terms: https://handbook.gitlab.com/handbook/about/handbook-usage/
Claim context: not recorded. Location: first character: 2162; last character: 4295.
Claim context not recorded: population, study or observation period, methodology, sample size. Do not assume these details or that the finding applies to this company.
Scope: Attributed source finding. It does not prove that the proposed test will work for this company.
Citation 7a92eb02-eb09-4e4d-9ff4-5f17966f4e81. Source version 3c55eacd-7799-45e7-9def-a01d26cc0a55.
Our interpretation, not a source conclusion: This organisation records a reason when an opportunity fails its own acceptance criteria. Our practical suggestion is to record why a case meets or misses your chosen condition. Its stages and rules are not a model you must copy.
[3] The Sales account leader/executive is responsible for taking the next step within 60 days, or reverting the opportunity back to BDR ownership or disqualifying the SAO if ultimately there is no opportunity.
GitLab | Field Operations Handbook - Segmentation section | Published: date not recorded | Evidence level C | RECOMMENDATION
Source: https://handbook.gitlab.com/handbook/sales/field-operations/gtm-resources/
Reuse terms: https://handbook.gitlab.com/handbook/about/handbook-usage/
Claim context: sales motion: sales-led; notes: GitLab handbook guidance on post-IQM ownership and escalation. Location: section: sfdc-users; first character: 0; last character: 584.
Claim context not recorded: population, study or observation period, methodology, sample size. Do not assume these details or that the finding applies to this company.
Scope: Attributed source finding. It does not prove that the proposed test will work for this company.
Citation e66d92b4-dd17-4aef-a1de-d952698c3a93. Source version af88fd77-99fd-482f-b375-28689a5dfe34.
Our interpretation, not a source conclusion: This is one organisation’s rule for next-step ownership and timing. Our practical suggestion is to make the next action and its owner explicit. The source’s time limit is not a deadline or benchmark for your company.
Limits of these source findings
- Applicability fields were not individually verified by the legacy review contract.
- Attributed source finding or practitioner judgement; empirical verification requirements are incomplete.
- No independently established corroboration; repeated sources do not increase confidence.
- Applicability not reported: motion
- Applicability not reported: segment
- Applicability not reported: geography
- Applicability not reported: currency
- Context not reported: motion
- Context not reported: segment
- Context not reported: geography
- Context not reported: currency
- Publication date is unknown; freshness and present-day effectiveness are not established. This is attributed practitioner guidance, not a benchmark or universal rule.
The test plan is product-authored diagnostic judgement, not an empirical benchmark, AI-verified diagnosis or guaranteed improvement.
Company answers are supplied observations, not independently verified facts.
The cited findings support their stated source claims. They do not prove this plan will work or establish independent consensus.
Research eligibility and rights were checked at release (2026-10-24T06:16:02.239319+00:00). This beta is not connected to the live corpus; withdrawals take effect on the next release, at most seven days without renewal.
Evidence release: 2026-10-24T06:16:02.239319+00:00. This downloaded copy does not update itself; reopen your review for the current release.
Source eligibility was checked for the release dated 24 October 2026. The public beta uses a bounded research snapshot, not a live connection to the private corpus.
YOUR DEALS DESERVE THEIR OWN REVIEW
Useful enough to try?
Bring your actual context.
Create your account, complete the short intake and download your own PDF or editable Word report. Come back to record what you tried and whether it helped.
Free beta. No card. No promised revenue uplift.