Every choice on this site is a default, not a law. These are the ones I would expect to argue about, and where I land.

GTM Operating Model › Trade-offs
Where reasonable people disagree
Every choice on this site is a default, not a law. These are the ones I would expect to argue about, and where I land.
Question
One way
The other way
Default on this site
When I would switch
SDR pods or full-cycle AEs
SDR pods: sales development reps prospect and book meetings for the AEs they are mapped to
Full-cycle: each account executive prospects, qualifies and closes their own book
I run SDR pods in mid-market and enterprise, and full-cycle AEs in SMB.
When research and first drafts are automated well enough that prospecting time stops competing with closing time.
Who owns the renewal
The CSM, who knows how the customer uses the product
The Account Manager, who runs renewal and expansion as one commercial conversation
The Account Manager in enterprise, the CSM in mid-market. SMB renews on auto-bill.
I would give renewals to Account Managers when they are mostly price conversations rather than value conversations.
MQL or PQL first, when both fire on the same account
MQL first: Marketing's score routes the person to an SDR
PQL first: product usage routes the account to sales-assist
The PQL wins the routing. The MQL stays on the record for attribution.
For a product with little usage signal before purchase, I would let the MQL lead.
Lead object or contact-only
A separate Lead record for people not yet matched to an account
Every person is a contact on an account from the first touch
I keep a Lead object for unmatched people, and carry the lifecycle state on the Account too.
When nearly all demand is account-based, I would go contact-only.
Forecast category: rep judgment or fixed by stage
The rep sets the category each period from what they know about the deal
The stage fixes the category, so there is no judgment to inspect
The rep sets it and the stage caps it.
For a large, junior team I would fix it by stage until the accuracy scorecard shows the reps call accurately.
Deal Desk inside RevOps or Finance
Inside RevOps: the team that approves non-standard pricing and terms sits next to the stage definitions and the CRM
Inside Finance, next to billing and revenue recognition
Alongside RevOps, with the approvals owned by Finance.
I would move it inside RevOps when deal volume is high and the terms are mostly standard.
Comp paid on booking or on cash
On booking: commission is paid when the contract is signed
On cash: commission is paid when the customer pays
I pay on booking, with a clawback window if the customer churns early.
I would pay on cash for long payment terms, or in a segment with high early churn.
Territories named or pooled
Named: each rep owns a fixed list of accounts
Pooled: accounts are assigned round-robin from a shared pool
By segment, as on the Territories page: named in enterprise, geography or industry in mid-market, pooled in SMB.
I would move SMB to named accounts when deal sizes rise enough to justify account planning.
Sourced credit by first touch or multi-touch
One channel gets the sourced credit for the opportunity
Multi-touch: credit is spread across every channel that touched the account
One sourced channel per opportunity, chosen by a fixed order of precedence. Multi-touch only for reading influence.
I would not switch for comp. Multi-touch is useful for reading influence and wrong for paying anyone.
Routing built in the CRM or bought
Native CRM assignment rules, built and kept by RevOps
A dedicated routing tool for matching and assignment
Native CRM rules.
I would buy when the matching needs fuzzy matching (records whose names or domains differ slightly) and account hierarchies.
Central RevOps or ops embedded in each function
Central: one team serves Marketing, Sales and Customer Success
Embedded: each function has its own operations team
Central for definitions, systems and the plan, with a named partner for each function.
I would move toward embedded only above the size where one team cannot hold the context.
Each default is the one drawn on the page it belongs to; this table is where the alternatives are written down. The switch conditions are deliberately qualitative: the thresholds depend on the company and belong in the plan model, not here.

How to read this

  • Each row names a real fork, the default this site draws, and the condition under which I would take the other branch.
  • The switch conditions are qualitative on purpose. The thresholds depend on the company and belong in the plan model.
  • One row has no switch: multi-touch attribution is fine for reading influence and is never used to pay anyone.
  • Most of these defaults change with size and segment rather than with taste. A full-cycle SMB team and an enterprise SDR pod can both be right inside the same company.

Where it connects

Diagram source: 24-tradeoffs.drawio 24-tradeoffs.svg