A self-reported operational assessment for established B2B teams entering a new region or segment. The five dimensions contain 25 questions. Equivalent controls in any stack count. Owning a vendor, paid subscription, or AI product earns no points by itself.
The public documents below explain product mechanisms and risk-management practices. The questions, evidence requests, levels, equal weights, and priorities are editorial choices. No source validates this rubric or your answers.
The result is not a certification, legal opinion, industry percentile, or prediction of revenue, ROI, conversion, or churn. There are no empirical performance benchmarks or survey statistics in the score. A reproducible segment does not establish market demand, willingness to pay, market size, or product-market fit.
Recording processing basis or consent does not establish compliance or permission for every channel and jurisdiction. Property visibility is not a complete security boundary. Use qualified legal and security review for activation decisions. Verification alone never grants permission to launch.
Market sources support explicit attributes, filter logic, and outcome review. They do not establish local-language effectiveness, actual regional data coverage, commercial demand, or regional legality. Questions about localization, coverage, research, handoff contents, renewal, and expansion are editorial operational evidence requests, not source-validated performance measures.
Exact score and unknown arithmetic
Each question has its own four evidence anchors, worth 0, 1, 2, or 3 points. Select the anchor that matches the control you can support. A number remains self-report, not independently verified evidence. Unknown means you cannot establish the control. An unanswered question is different from Unknown.
Level 3 is cumulative. It requires the working level 2 control as well as the additional operating evidence. Its displayed anchor includes both requirements. Select a lower level if either is not established.
Each dimension has five questions and a fixed maximum of 15 points. No unanswered or unknown answer reduces that denominator.
The reported lower score is round(100 × sum of numeric answers ÷ 15). Unknown and unanswered answers contribute no evidenced points, but are not classified as absent controls.
The potential ceiling is round(100 × (sum of numeric answers + 3 × (unknown count + unanswered count)) ÷ 15). This is an uncertainty bound, not a forecast.
For example, 3, 2, 1, 0, and Unknown give 6 evidenced points, a 40% lower score, and a 60% ceiling. Known coverage is 4 of 5. Response completeness is 5 of 5.
Five Unknown responses are complete but have no known coverage. Their arithmetic range is 0% to 100%, labelled Not established rather than absent. No maturity band is assigned over an unknown range.
All 25 responses, including Unknown, are required for a complete result. An unanswered question creates no inferred action. A draft is incomplete even when some dimensions have scores.
Priorities, dependencies, and a conditional 90-day plan
Unknown creates an evidence-verification action. Levels 0 and 1 create a repair action. Level 2 creates an improvement action. Level 3 creates no gap action. Each action names an owner, an evidence or delivery step, and a completion condition from the question catalogue.
Phase 1, the first 30 days, prioritizes safety and foundation repairs and verification. Safety improvements also stay in phase 1.
Phase 2, days 31 to 60, contains market repairs and verification, conditional on their prerequisites.
Phase 3, days 61 to 90, contains workflow repairs and verification, plus non-safety improvements.
Within a phase, the declared priority order is safety, foundation, market, then workflow. Severity orders Unknown verification before level 0 repair, level 1 repair, then level 2 improvement. Stable catalogue order breaks remaining ties. Prerequisite actions precede their dependents, overriding that rank when needed.
A prerequisite requires a known answer of at least 2. Unknown, unanswered, 0, or 1 does not clear it. The plan exposes unresolved direct and transitive prerequisites for answered controls, including level 3 controls without gap actions and blockers reached through a known intermediate control. A dependent action moves to a later phase when an unresolved prerequisite action requires that phase.
If all 25 answers are 3, the plan contains three maintenance reviews instead of invented gaps. Phase 1 rechecks evidence, phase 2 samples market and workflow records, and phase 3 reviews operations.
The 90-day window is an editorial planning frame, not a delivery promise. Dependencies, legal review, evidence gaps, capacity, and procurement can extend it. A high score never overrides a material blocker or makes later rollout unconditional.
Deterministic scoring and shareable URL privacy
The assessment calculates scores and actions locally using a deterministic rubric. It makes no assessment network requests, AI calls, or browser-storage writes. Existing analytics, request-form behavior, and root mounting are unchanged. Header and footer navigation add the assessment link. This is not a claim that the entire site makes no network requests.
The versioned fragment uses #gtm-v1.<25 answer tokens>.<view>. Tokens are _ for unanswered, u for Unknown, and 0 through 3 for self-reported levels. Views 0 through 4 identify a dimension and view 5 identifies results. The fragment contains selections and view only. Scores are recalculated, never trusted from URL data.
A results URL requires all 25 responses. Malformed fragments, unsupported versions, and incomplete results are rejected without salvaging partial answers. Version v1 fixes the question order and answer meaning. Future semantic changes require a new version.
Anyone with the URL can read your selections. Fragments are not part of the normal HTTP request to the server, but browser scripts, history, clipboard recipients, screenshots, and printed reports can expose them. This is not encrypted or confidential storage. No company fields, free text, customer records, or credentials are requested. Keep the underlying evidence in your own approved systems.
Every question and its evidence anchors
These rationales and evidence requests are editorial extensions of the narrower documented facts. Source links explain the mechanism, not the validity of a maturity score. Review actual entry paths and operating records rather than a product logo or an installed integration.
Stack connectivity
Trace records and signals across CRM, warehouse, enrichment, outbound and product systems. Equivalent controls in any stack count.
stack.1. Can you trace the same account and contact from CRM through warehouse, enrichment and outbound?
S01 distinguishes record matching from field mapping; a connected app alone does not establish shared identity.
Evidence to inspect. Matching rules, paired record IDs and one mismatched record across the actual systems.
No cross-system matching rule exists.
Some records match, but teams reconcile identities manually.
Documented matching rules work on sampled records across the launch path.
Documented matching rules work on sampled records across the launch path. An owner reviews mismatches and retests identity rules after changes.
Unknown. The evidence is not known or cannot be established.
Declared priority is foundation. No question prerequisites are declared.
stack.3. When CRM, warehouse or enrichment disagree, is the winning value for each critical field explicit?
S02 separates conflict priority from sync direction; neither setting alone resolves business ownership.
Evidence to inspect. Field ownership rules and a conflict test showing the expected winning value.
Conflicting values overwrite one another without an agreed rule.
Teams resolve conflicts case by case.
Critical fields have agreed authoritative systems and a tested conflict rule.
Critical fields have agreed authoritative systems and a tested conflict rule. Owners monitor conflicting writes and review authority rules after changes.
Unknown. The evidence is not known or cannot be established.
Declared priority is foundation. Prerequisites require a known level of at least 2.
stack.4. Can repeated, late or failed product and CRM events recover without duplicate customer-facing actions?
S03 describes these risks for Stripe events; ask other providers about their own guarantees rather than assuming identical behavior.
Evidence to inspect. Duplicate, out-of-order and failed-event tests, a recovery trace and applicable signature checks.
Retries or repeated events can repeat an action, with no recovery control.
Failures are replayed manually without duplicate or ordering checks.
Critical flows pass duplicate, ordering and safe-recovery tests with authenticated inputs.
Critical flows pass duplicate, ordering and safe-recovery tests with authenticated inputs. An owner monitors failures and periodically exercises safe replay and recovery.
Unknown. The evidence is not known or cannot be established.
Declared priority is safety. Prerequisites require a known level of at least 2.
stack.5. Does a named owner review failed and excluded CRM, enrichment and warehouse records?
S02 and S03 expose failure states; successful delivery is not proof that downstream processing completed.
Evidence to inspect. A recent exception queue, owner review and resolved failure with downstream confirmation.
No one reviews integration exceptions.
Failures are noticed only when a seller reports missing data.
A named owner reviews a queue and can resolve a failed or excluded record.
A named owner reviews a queue and can resolve a failed or excluded record. Review cadence, escalation and downstream recovery checks are routinely evidenced.
Unknown. The evidence is not known or cannot be established.
Declared priority is foundation. Prerequisites require a known level of at least 2.
data.3. Before regional outbound, can you trace contact origin, processing basis, channel permission and suppression?
S05 supports recording processing basis, not certifying legality; processing basis and permission to communicate are distinct.
Evidence to inspect. A source/provenance record, relevant basis and channel-status evidence, suppression trace and jurisdiction-specific legal review.
Activation uses contacts without provenance or permitted-use checks.
Source is recorded, but basis, channel permission or suppression is incomplete.
Launch records have reviewed provenance, permitted-use and suppression checks for the region.
Launch records have reviewed provenance, permitted-use and suppression checks for the region. An accountable owner rechecks changes and samples suppression through every activation path.
Unknown. The evidence is not known or cannot be established.
Declared priority is safety. No question prerequisites are declared.
data.4. Who owns critical CRM and warehouse definitions, freshness expectations and changes?
S02 supports field authority. Applying S09's documented-responsibility pattern to GTM data stewardship is an editorial extension.
Evidence to inspect. Named stewards, field definitions, freshness rules and a reviewed change or ownership dispute.
Critical definitions and changes have no accountable owner.
Definitions exist, but ownership or freshness expectations are informal.
Stewards own definitions, freshness expectations and a change-review rule.
Stewards own definitions, freshness expectations and a change-review rule. Stewards review stale-data exceptions and document approved changes and consumer impact.
Unknown. The evidence is not known or cannot be established.
Declared priority is foundation. Prerequisites require a known level of at least 2.
data.5. Do sensitive-data controls cover integration and API access, not only hidden CRM fields?
S06 warns property visibility is not a security boundary; S11 recommends least privilege for scopes and roles.
Evidence to inspect. Actual app scopes, user roles and a reviewed API or automation sensitive-field access path.
Sensitive data is broadly accessible without reviewed controls.
CRM screens hide fields, but integration or API access has not been reviewed.
Roles and actual app access are reviewed against required sensitive-data use.
Roles and actual app access are reviewed against required sensitive-data use. An owner regularly tests access boundaries and removes obsolete authority.
Unknown. The evidence is not known or cannot be established.
Declared priority is safety. No question prerequisites are declared.
Bound tasks, authority, approval, quality and recovery. Using AI is not required.
automation.1. Does each automated or agent-assisted GTM workflow have a named owner and bounded task?
S09 GOVERN 2.1 supports assigned responsibilities and task scope; it does not require deploying an agent.
Evidence to inspect. Purpose, owner, inputs, allowed actions and escalation boundary for a real workflow.
Workflows run without a named owner or permitted-task boundary.
An owner is named, but inputs, allowed actions or escalation are unclear.
Each launch workflow has a named accountable owner and documented inputs, permitted actions and escalation.
Each launch workflow has a named accountable owner and documented inputs, permitted actions and escalation. Owners review scope when tools, data or business use changes.
Unknown. The evidence is not known or cannot be established.
Declared priority is foundation. No question prerequisites are declared.
automation.2. Do workflow and agent credentials grant only the CRM, enrichment or outbound authority needed?
S11 recommends least privilege and obsolete-app removal; a service-account name is not scope evidence.
Evidence to inspect. Actual read/write scopes, role review and an obsolete-access removal record.
Workflows use broad admin credentials without review.
Dedicated credentials exist, but their actual scopes are unchecked.
Actual roles and scopes match the documented task and obsolete access is removed.
Actual roles and scopes match the documented task and obsolete access is removed. An owner reviews access after task changes and periodically checks credential lifecycle.
Unknown. The evidence is not known or cannot be established.
Declared priority is safety. Prerequisites require a known level of at least 2.
automation.4. Are workflow or agent changes tested on representative cases before release?
S08 and S09 MEASURE support task-specific evaluation; no illustrative vendor threshold is used here.
Evidence to inspect. Versioned cases, explicit acceptance criteria, observed failures and a release decision.
Changes ship after a demonstration with no acceptance cases.
Happy-path checks exist but lack explicit criteria or failure cases.
Representative and failure cases have explicit criteria and a recorded release decision.
Representative and failure cases have explicit criteria and a recorded release decision. Cases are updated from incidents and rerun after relevant changes and during operation.
Unknown. The evidence is not known or cannot be established.
Declared priority is foundation. Prerequisites require a known level of at least 2.
automation.5. Can an accountable person stop unsafe automation and recover without assuming previous writes are undone?
S09 MANAGE 2.4 and 4.1 support stop and incident controls; S02 stopping sync does not mean rollback.
Evidence to inspect. Alert ownership, stop procedure and a recovery or override exercise with prior-write review.
No accountable person or practical stop procedure exists.
A stop button exists, but alerts, recovery or prior writes are unowned.
A named owner has exercised stop, escalation and recovery including prior-write review.
A named owner has exercised stop, escalation and recovery including prior-write review. Owners periodically exercise incidents and update controls from operational findings.
Unknown. The evidence is not known or cannot be established.
Declared priority is safety. Prerequisites require a known level of at least 2.
Make new-region coverage and cohort logic inspectable. Readiness is not proof of demand or legal permission.
market.1. Is the new region or segment ICP expressed as testable account and buyer attributes, including exclusions?
S10 fit rules use properties and associated records; inspectable rules do not establish commercial demand.
Evidence to inspect. Region/segment scope, account and buying-role criteria, exclusions and required property definitions.
The target is a broad region or segment label without testable criteria.
Some account traits are listed, but buyer roles or exclusions are missing.
Account, buyer-role and exclusion criteria are explicit and testable for the launch cohort.
Account, buyer-role and exclusion criteria are explicit and testable for the launch cohort. An owner reviews criteria against observed cohort outcomes and records changes.
Unknown. The evidence is not known or cannot be established.
Declared priority is market. Prerequisites require a known level of at least 2.
market.2. Does new-market prioritization distinguish account fit from engagement or product signals?
S10 distinguishes fit and engagement; activity alone does not establish fit or intent to buy.
Evidence to inspect. Separate fit and signal rules, missing-signal treatment and a high-engagement poor-fit example.
Activity or product usage alone determines priority.
Fit and engagement are mentioned but blended into an unexplained score.
Fit and engagement/product-signal rules are separately explainable, including missing data.
Fit and engagement/product-signal rules are separately explainable, including missing data. Owners review false priorities against sales outcomes and adjust the separate rules.
Unknown. The evidence is not known or cannot be established.
Declared priority is market. Prerequisites require a known level of at least 2.
market.3. Can you reproduce new-region account and buyer coverage from sourcing through the saved launch segment?
S10 and S12 support explicit populations and membership logic. Source-coverage review is an editorial request, not a market-size estimate.
Evidence to inspect. Source coverage and missingness review, saved membership logic, territory associations and inclusion/exclusion examples.
The launch list cannot be reproduced or its source coverage explained.
A sourced list exists, but missing buyers, territory rules or membership changes are unclear.
Saved rules reproduce the cohort, with source gaps and buyer/territory associations documented.
Saved rules reproduce the cohort, with source gaps and buyer/territory associations documented. An owner reviews coverage gaps and membership drift after sourcing or rule changes.
Unknown. The evidence is not known or cannot be established.
Declared priority is market. Prerequisites require a known level of at least 2.
market.4. Have new-segment and territory rules passed positive, exclusion and boundary-case checks?
S12 shows operators and association scope can change membership; correct logic is not proof of attractive demand.
Evidence to inspect. Reviewed positive, excluded, boundary and associated-record cases with unexpected results explained.
Launch membership is not tested.
A few positive records are checked without exclusions or boundaries.
Positive, excluded, boundary and association cases match documented expectations.
Positive, excluded, boundary and association cases match documented expectations. The case set is rerun after changes and unexpected membership has an assigned reviewer.
Unknown. The evidence is not known or cannot be established.
Declared priority is market. Prerequisites require a known level of at least 2.
market.5. Are new-market qualification rules reviewed against acceptance, progression and losses rather than list size alone?
S10 describes outcome review and S14 exposes progression; neither supplies a transferable sample-size or forecasting benchmark.
Evidence to inspect. A dated cohort review of sales acceptance, deal progression, loss reasons and rule-change decisions.
The team judges launch readiness only by list size or activity.
Sales anecdotes exist, but no cohort outcome review is recorded.
A cohort review connects qualification rules to acceptance, progression and losses.
A cohort review connects qualification rules to acceptance, progression and losses. An owner repeats reviews, tracks data limits and records rule-change decisions.
Unknown. The evidence is not known or cannot be established.
Declared priority is market. Prerequisites require a known level of at least 2.
Turn research, meetings and product signals into accountable sales and customer work.
workflow.1. Does AE account research arrive with traceable sources and an eligible owner, including an unassigned path?
S13 supports eligible ownership and routing exceptions. Research-packet contents are editorial evidence requests, not vendor-prescribed fields.
Evidence to inspect. A research packet with source/freshness context, owner rules and an unassigned-record example.
AE research is scattered and records have no reliable receiving owner.
Research packets exist, but sources or owner exceptions are manual and unclear.
A sourced research packet reaches an eligible AE and unassigned records enter a monitored queue.
A sourced research packet reaches an eligible AE and unassigned records enter a monitored queue. Owners sample research relevance, freshness and routing exceptions and improve the handoff.
Unknown. The evidence is not known or cannot be established.
Declared priority is workflow. Prerequisites require a known level of at least 2.
workflow.2. Do meetings produce CRM outcomes, next actions and observable follow-up exceptions?
S14 supports stage and follow-up timing. Meeting contents and response expectations are team-defined, not universal vendor SLAs.
Evidence to inspect. A meeting-linked CRM outcome, next owner/action, usable timestamp and overdue queue.
Meeting outcomes and next actions are not reliably recorded.
Notes are stored, but next owner, timestamp or overdue handling is inconsistent.
Meetings produce agreed CRM outcomes, next actions and a monitored overdue queue.
Meetings produce agreed CRM outcomes, next actions and a monitored overdue queue. Sales ops samples missing outcomes and overdue follow-up and closes recurring gaps.
Unknown. The evidence is not known or cannot be established.
Declared priority is workflow. Prerequisites require a known level of at least 2.
workflow.4. Do product-usage alerts reach an AE or CSM with an explainable reason and next action?
S15 supports explainable segment-specific health signals and S13 accountable assignment. Product relevance must be established by the team.
Evidence to inspect. A product event trace, account association, segment-relevant alert rule and resulting owned task.
Product signals stay in dashboards with no receiving owner.
Alerts are sent, but account matching, rationale or next action is unclear.
Relevant signals reach the correct AE/CSM with an explainable reason and owned action.
Relevant signals reach the correct AE/CSM with an explainable reason and owned action. Owners review noisy, missing and resolved alerts and retest rules after changes.
Unknown. The evidence is not known or cannot be established.
Declared priority is workflow. Prerequisites require a known level of at least 2.
workflow.5. Can CS explain renewal and expansion priorities and feed action outcomes back into the rules?
S15 and S10 support inspectable scoring and outcome review; a score does not inherently predict renewal or expansion.
Evidence to inspect. Segment-specific health inputs, renewal context, expansion rationale, named owner and a reviewed action outcome.
Renewal and expansion work is reactive with no explainable prioritization.
A health score exists, but renewal/expansion reasons or action owners are unclear.
CS priorities explain segment-relevant inputs, renewal context and owned next actions.
CS priorities explain segment-relevant inputs, renewal context and owned next actions. CS reviews action outcomes, false priorities and renewal/expansion rule decisions on a stated cadence.
Unknown. The evidence is not known or cannot be established.
Declared priority is workflow. Prerequisites require a known level of at least 2.
Each source was opened and its relevant text inspected on the date shown. A readable document is not a product test, an inspection of your configuration, or independent reproduction of vendor claims. No HTTP status-code claim is made. Vendor-specific behavior does not automatically apply to another provider.
HubSpot appears frequently because the scope emphasizes CRM operations. Equivalent controls in Salesforce or another stack count. Some documented controls require paid tiers or seats. The assessment does not require buying those products.
Documented support. GOVERN 2.1 and 3.2 responsibilities and oversight; MEASURE testing; MANAGE 2.4 and 4.1 stop and incident controls.
Limit. Voluntary guidance, not assessment endorsement, certification, GTM weights or a statutory threshold; data stewardship is an editorial extension.
S10. Build lead scores to qualify contacts, companies, and deals
Documented support. Segment-specific explainable customer-health inputs, testing and review.
Limit. Paid features apply. Scores do not inherently predict renewal or prove churn reduction; usage and expansion signals need team-specific evidence.
Playbooks for assessment priorities
Result actions link to these published playbooks when their mapped questions need attention. Catalogue and skill links remain available alongside them. A playbook is an implementation resource, not independent verification of an answer or permission to activate a workflow.