GTM Systems Teardown Rubric

Check 1: Ownership

Question

Does every inbound lead, account and alert have exactly one named owner of record, set by a rule at the moment the record is created?

Failure smell

Leads sit with an empty owner or with an integration user as owner, reps ask in Slack who has an account, and two reps work the same buyer while another lead waits with nobody.

How to measure it

Count records created in the window where owner_id is null or points at an inactive or integration user, and count accounts whose open contacts carry more than one distinct owner_id. For any record older than the assignment step, both counts should be zero.

The fix

Resolve the owner in one place and in a fixed order: existing account owner, then the territory table, then a round-robin pool that respects availability, then a named fallback owner. Write owner_id and owner_assigned_at in the same step that creates the record, and alert on any record that leaves that step without both.

The owner-versus-rotation decision itself is covered in round-robin vs ownership routing.

Patterns

• Owner-of-Record Routing

Debugger levels that exercise this check

• Level 1: The unanswered demo request
• Level 5: The dropped handoff
• Level 9: The alert nobody owns

Play them in the Pipeline Debugger.

Check 2: Latency

Question

Does a hand-raise (a demo request, a contact-sales form, a reply) reach a human who acts on it inside the sub-5-minute standard, around the clock, with an escalation when nobody does?

Failure smell

Response time is a feeling rather than a number, the median only looks healthy because off-hours leads are left out of it, and a form filled on Friday evening gets its first touch on Monday.

How to measure it

Stamp lead_created_at and first_touch_at on every inbound record and compute response_minutes = first_touch_at - lead_created_at. Report the median and the slowest decile across all 168 hours of the week, split by source and by in-hours versus off-hours, and count records where first_touch_at is still null.

The fix

Start a timer at lead_created_at that escalates while claimed_at is empty: to the pool at the first threshold, to a manager at the second. Send an automated first touch to after-hours leads so the buyer hears back in minutes, and log it apart from the human first touch so it never flatters the number.

The full build is in the speed-to-lead implementation guide, the alert and timer layer in Slack and SMS lead alerts, and off-hours coverage in after-hours lead response.

Patterns

• SLA Timer with Escalation
• Four-Timestamp Write-Back
• Capacity-Bound Threshold Bands

Debugger levels that exercise this check

• Level 1: The unanswered demo request
• Level 9: The alert nobody owns

Play them in the Pipeline Debugger.

Sources

• Harvard Business Review (March 2011, Oldroyd, McElheran, Elkington), "The Short Life of Online Sales Leads": put the average first response to a web lead near 42 hours, in a review of how companies answered inbound web leads.
• Lead Response Management study (Oldroyd, 2007): found leads worked within 5 minutes roughly 21x likelier to qualify than leads worked at 30 minutes (directional). Named, not linked: the study has no live canonical home.

Check 3: Idempotency and dedup

Question

When the same event arrives twice (a resubmitted form, a retried webhook, a visitor back in a new session), does the system still create one record, one sequence enrollment and one alert?

Failure smell

Contacts that differ only by letter case or a trailing space in the email, a buyer enrolled in two sequences by two workflows, and an alert channel where the same visitor appears several times a week.

How to measure it

Group contacts by normalized_email (lowercased and trimmed) and accounts by normalized_domain, and count groups holding more than one record. For events, log an event_id or a hash of source, payload key and time bucket, and count keys processed more than once. For alerts, count alerts per contact_id inside one dedup window.

The fix

Give every inbound event an idempotency key and refuse a second write with a key already seen; upsert on normalized_email instead of inserting. Thread repeat signals for one contact under the original alert for the length of a dedup window instead of posting a new one.

Duplicate records are also a data-quality problem upstream of any workflow; see CRM data quality.

Patterns

• Idempotent Event Ingestion
• Alert Dedup Window

Debugger levels that exercise this check

• Level 8: The forked record
• Level 9: The alert nobody owns

Play them in the Pipeline Debugger.

Sources

• Stripe API reference, "Idempotent requests": documents the idempotency-key mechanism, where a retried request with the same key returns the first result instead of acting twice.
• HubSpot Knowledge Base, "Deduplicate records in HubSpot": documents how the HubSpot CRM finds and merges duplicate contacts and companies.
• Google, Site Reliability Engineering, "Monitoring Distributed Systems": argues that every page to an on-call engineer should be actionable, the same rule a dedup window enforces on lead alerts.

Check 4: Suppression

Question

Before any outbound send, is every recipient checked against one suppression list that holds customers, open opportunities, unsubscribes, bounces, competitors and do-not-contact requests?

Failure smell

A current customer gets a cold first-touch email, a rep's open deal receives an SDR sequence, an address that unsubscribed in one tool is mailed by another, and suppression lives in several tool-level lists that disagree.

How to measure it

Join each sequence's enrolled contacts against customer accounts, open opportunities, global_unsubscribe, hard_bounce and do_not_contact, and count the matches; the count should be zero, and any match names the gap. Stamp unsubscribed_at in every sending tool and check that an unsubscribe recorded in one tool reaches the others.

The fix

Keep one suppression ring in the system of record, and have every sending tool read it at enrollment and again just before each step sends. Write unsubscribes and bounces back to that ring from every tool, and treat a failed lookup as suppress, never as send.

Patterns

• Suppression Ring

Debugger levels that exercise this check

• Level 10: The sequence that emailed a customer
• Level 8: The forked record

Play them in the Pipeline Debugger.

Sources

• CAN-SPAM Rule, 16 CFR Part 316 (US Federal Trade Commission, via eCFR): the US commercial email rule, which requires a working opt-out mechanism and that opt-out requests are honored.
• Google, Gmail Help, "Email sender guidelines": sets requirements for anyone sending to Gmail accounts, including unsubscribe handling for bulk senders.

Check 5: Consent and region

Question

Does visitor identification respect the visitor's region: opt-out in the United States, opt-in everywhere else, and never person-level in the EEA, the UK or Switzerland?

Failure smell

The identification script loads before the region is known, European visitors arrive in the alert channel as named people, a Global Privacy Control signal is ignored, and nobody can say which rule applied to which identified visit.

How to measure it

For each identified visit, log region (us, eea_uk_ch, other or unknown), consent_state at the moment of identification, gpc_signal and identification_level (company or person). Count person-level rows where region is eea_uk_ch, rows identified before consent outside the US, rows identified while gpc_signal was true, and rows with region unknown that ran anything beyond the consent-first default. Each count should be zero.

The fix

Resolve the region first and gate every identification script and enrichment call on it: in the United States run by default and stop on an opt-out or a Global Privacy Control signal; everywhere else wait for consent; in the EEA, the UK and Switzerland stay company-level even after consent; when the region is unknown, apply the consent-first rules. Write region and consent_state onto the record so the rule that applied can be audited later.

This is the region model artemisgtm.ai runs itself, described in the privacy policy. It is engineering guidance, not legal advice: your counsel sets the rule for your company. The identification mechanics are in how visitor identification works and person vs company-level identification.

Patterns

• Consent-Gated Identification

Debugger levels that exercise this check

• Level 2: The invisible visitor

Play them in the Pipeline Debugger.

Sources

• European Data Protection Board, Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive: sets out which tracking techniques fall under the ePrivacy consent rule.
• Global Privacy Control: the browser signal a visitor uses to send an opt-out of the sale or sharing of their data.

Check 6: Enrichment waterfall

Question

When the first enrichment provider returns nothing or a stale value, does the record fall through to the next source in a fixed order, with the source and date of every field recorded?

Failure smell

Records sit with a blank title, company size or industry because one provider missed, sequences go out with a generic greeting or the wrong persona copy, and nobody can tell which vendor supplied a field or when.

How to measure it

For each field that drives routing, scoring or copy (job_title, employee_count, industry, email), compute the fill rate by source and by month, and count records where field_source or field_enriched_at is null. Record email verification status at send time, not at import.

The fix

Order providers per field, call the next provider only when the previous one returns empty or falls below a confidence floor, and stop at the first verified value. Write field_source and field_enriched_at beside each value, and send records that exhaust the waterfall to a review queue instead of into a sequence.

Patterns

• Enrichment Waterfall with Fallback

Debugger levels that exercise this check

• Level 4: The silent sequence
• Level 3: The wrong list

Play them in the Pipeline Debugger.

Check 7: CRM write-back and reporting

Question

Does every step write its timestamp and outcome back to the CRM record, against one shared handoff definition, so the funnel report is computed from fields instead of rebuilt from tool dashboards?

Failure smell

Marketing and sales report different MQL counts for the same month, response time cannot be computed because only the create date is stored, and accepted, rejected and recycled leads look identical in the CRM.

How to measure it

Check that each inbound record carries lead_created_at, alert_sent_at, claimed_at and first_touch_at, plus mql_at and either sql_accepted_at or sql_rejected_at with a rejection_reason. Count records that reached a later stage with an earlier timestamp missing, and compare the MQL count in the CRM with the count each tool reports for the same window.

The fix

Agree one written MQL-to-SQL definition with entry criteria, exit criteria and a fixed list of rejection reasons, and make it the only thing that moves lifecycle stage. Have every tool write its timestamp to the shared record instead of its own log, then build the funnel report from those fields alone.

The handoff definition is worked through in the MQL-to-SQL handoff, and the four timestamps in Slack and SMS lead alerts.

Patterns

• Four-Timestamp Write-Back
• Shared Handoff Definition

Debugger levels that exercise this check

• Level 5: The dropped handoff
• Level 9: The alert nobody owns
• Level 6: The cold middle

Play them in the Pipeline Debugger.

Sources

• HubSpot blog, "How to create a service level agreement (SLA) for better sales and marketing alignment": a guide to writing the shared sales and marketing agreement that a handoff definition formalizes.

Check 8: Verification loop

Question

Is there a scheduled end-to-end test that pushes a synthetic lead through the live system and checks every expected outcome, so a break is found by the test and not by a buyer?

Failure smell

A workflow stopped silently after a token expired or a field was renamed, the team found out from a lost deal or a complaint, and "it worked when we launched it" is the only evidence that it works now.

How to measure it

Keep a list of expected outcomes for a tagged test record (record created, owner_id set, alert posted, sequence enrolled or suppressed, timestamps written) and run it against production on a schedule. Log verify_run_at, the result of each expected outcome and the time since the last fully passing run, and alert when an outcome fails or a scheduled run does not happen.

The fix

Seed tagged test records that exercise each path, such as a fit inbound lead, a customer that must be suppressed and a visitor from a consent-first region, and assert every outcome after each run. Exclude the test tag from reporting, and treat a failed or missing run as an incident with an owner.

Patterns

• Verify Loop
• Read-Only Audit Pass

Debugger levels that exercise this check

• Level 2: The invisible visitor
• Level 10: The sequence that emailed a customer
• Level 7: The same page for everyone

Play them in the Pipeline Debugger.

Sources

• Google, Site Reliability Engineering, "Monitoring Distributed Systems": separates black-box monitoring, which tests behavior the way a user sees it, from white-box monitoring of internals.

Self-Check: score your own system

Mark each check Pass, Fail or Unsure for the system you run. Every check starts at Unsure, because that is the honest answer before you look. The page keeps nothing: your answers live in this tab and are gone when you close it, and nothing is sent unless you send it yourself through one of the paths below.