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.
STALLED DEALS / EXAMPLE REPORT
Why do our enterprise deals stall at technical validation?
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 sales manager and the people responsible for the deals. Confirm the person and their capacity; nobody has accepted work through this report.
Do not rename the CRM stage or add a chase sequence until you understand what the buyer is waiting for.
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.
- For your enterprise segment, include procurement, technical review and implementation dependencies when the actual buying process contains them. Do not assume every deal has every approval.
- Your supplied ACV is GBP 40,000. Use comparable deal scope when choosing cases; that amount does not prescribe a universal process or target.
- Your supplied cycle is 120 days. Use it with actual stage history to choose the follow-up window; still-open deals are not automatically failures.
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 | technical validation |
| 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 | Separate avoidable delay from real buyer dependencies without adding pointless admin. |
| Suggested owner | The current sales manager and the people responsible for the deals. 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 and comparable group | Record the answer, its date and supporting record. Leave unknowns visible. |
| Last buyer action and date | Record the answer, its date and supporting record. Leave unknowns visible. |
| Next milestone, agreed date and owner | Record the answer, its date and supporting record. Leave unknowns visible. |
| Dependency, supporting detail and current status | 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 sales manager and the people responsible for the deals 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 If the same preventable dependency recurs, pilot one change to how that milestone is agreed or recorded. Do not treat all delays as the same problem. | Suggested owner: The current sales manager and the people responsible for the deals 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 Test a change where the same fixable dependency keeps appearing. Renaming a CRM stage won't resolve a buyer's timing problem. | Suggested owner: The current sales manager and the people responsible for the deals 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 |
|---|---|
| Days since buyer action | Observation date minus the last dated, confirmed buyer action. A missing date stays unknown. A seller sending an email doesn't count as the buyer moving. |
| Missed milestones | Count agreed milestones whose dates passed without completion. Record whether the buyer moved the date and why, if known. |
| Reason for delay | Keep what the buyer confirmed separate from what the seller thinks. If nobody knows, write unknown. |
Keep the comparison fair: Compare delayed and progressing deals at the same step with similar customer groups. Include procurement and implementation dependencies where they actually exist.
You reported a 120-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 |
| Sales team | 4 account executives |
| Question | Why do our enterprise deals stall at technical validation? |
| Main concern | Opportunities that appear to stall |
| Where it happens — your description | technical validation |
| Stage criteria | explicit |
| Recent deal observations | Fictional examples: one buyer is waiting for security approval; another has not agreed when to evaluate the product. Both deals are labelled technical validation. |
| Desired outcome | Separate avoidable delay from real buyer dependencies without adding pointless admin. |
| Customer segment | enterprise |
| Sales motion | sales-led |
| Average contract value | GBP 40,000 |
| Sales cycle | 120 days |
06The method and its limits
Possibility to examine: The same buyer milestone or dependency might be holding up several deals. We haven't established that pattern yet.
Another explanation to keep in view: Buyer timing, procurement, changed priorities or missing notes might explain the delay. Another follow-up email may change none of them.
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.
- For enterprise deals, record procurement, legal and implementation dependencies where they exist. Don't invent them for every deal.
- Use your reported 120-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] 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.
[2] 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.
[3] 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.
Limits of these source findings
- Publication date is unknown; freshness and present-day effectiveness are not established. This is attributed practitioner guidance, not a benchmark or universal rule.
- 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
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.