GTM Systems Design

Every enrichment formula, scoring rule and routing decision sits on top of one thing: a data model that knows what a person and a company are. Get the objects wrong and every downstream system inherits the mess.

At Cursor the model is unusually leaky, because the strongest buying signal isn't a form fill. It's a developer who signed up, opened the editor and ran the agent forty times this week. A GTM Engineer who treats product usage as a second-class input next to marketing leads has already lost the plot for a developer-led, PLG-to-enterprise motion.

Start the interview answer by naming the objects and how they relate, not by jumping to a tool.

The hard part is identity resolution: stitching a lead that arrived as a personal Gmail to the account it actually belongs to and recognizing that the same human shows up as a product sign-up, a webinar registrant and a partner referral.

Source of truth: CRM, warehouse or bothname the boundary

A common interview trap is declaring "the CRM is the source of truth" and stopping. The honest answer splits responsibility by what each system is good at.

Dedup and merge

Dedup is where good schemas get tested. You need matching keys, a fuzzy fallback and a deterministic conflict-resolution rule so two runs never disagree.

1. 1Exact keys first. Normalize and match on email and company domain. Lowercase, strip plus-addressing, map gmail.com/googlemail.com. Most matches resolve here, cheaply and unambiguously.
2. 2Fuzzy fallback. When exact fails, match on normalized company name plus enriched domain or person name plus account. Set a similarity threshold and route anything below it to manual review instead of guessing.
3. 3Deterministic conflict resolution. When two records disagree on a field, pick the winner by an explicit rule: most recent verified value or highest-trust source. Never "last write wins" by accident.
4. 4Merge, don't delete. Collapse duplicates into a survivor record but keep the merge history, so a wrong merge is reversible and an audit can see what happened.

A schema that survives new segments

The role explicitly asks for systems that extend as new geos, segments and program types are added. A schema hard-codes that future or fights it.

• Model program membership as a row in a join table (account_program), not a boolean column per program - so adding a partnerships program is data, not a migration.
• Keep firmographics, technographics and usage as separate field groups with their own freshness timestamps, since they decay at different rates.
• Store the reason a field has its value (which provider, which run) so you can debug coverage later.
• Give every object a stable internal id that survives CRM record churn, so usage events captured before a lead is created can attach retroactively.

No single data provider knows everything. Waterfall enrichment is the answer: try providers in sequence until a field is filled and you routinely double or triple the match rate of any one vendor.

This is the single most likely thing the practical round asks you to build. A Clay-style table where a domain comes in and a rich, scored profile comes out is the canonical GTM Engineer exercise and the waterfall is its engine.

What a waterfall actually does

For each field you want, you call providers in a chosen order and stop the moment the field is populated. The next record might fill the same field on the first try and skip the rest entirely.

1. 1Try provider 1. Cheapest or highest-hit-rate vendor for this field. If it returns a confident value, mark the field filled and stop.
2. 2Fall through on miss. Empty or low-confidence result, move to provider 2. Repeat down the chain.
3. 3Stop early. The instant a field is filled, skip every remaining provider for that field - that's where the cost savings come from.
4. 4Record provenance. Store which provider filled each field and when, so freshness and conflict resolution have something to reason about.

Cost vs. coverage

Every provider call costs money and latency. The whole design is a dial between filling more fields and spending less.

Caching and freshness

Re-enriching a record you already have is the most common way GTM bills balloon. Cache aggressively, but give cached values a shelf life.

• Key the cache by normalized domain or email plus field name, so a hit skips the entire chain for that field.
• Attach a TTL per field group: a company's headcount can be weeks stale, a person's current employer should expire sooner.
• On a stale read, re-enrich in the background and serve the old value now - don't block the pipeline waiting for freshness.
• Track a per-provider hit-rate over time; a vendor whose coverage quietly drops should fall in the order.

Failure handling

Providers rate-limit, time out and return partial matches. A waterfall has to degrade rather than break, because a stalled pipeline is worse than a half-filled record.

A score that nobody acts on is a vanity number. Scoring earns its place only when a threshold sends a lead somewhere different - to a rep, to nurture or to the bin.

For Cursor the ICP can't be the usual firmographic checklist, because the best lead might be a two-person startup whose engineers are running the agent every day. Define the ideal customer profile across three input families, then weight them for a developer-led motion.

Point-based vs. model-based

Both have a place and the interview reward goes to the one whose tradeoff you can articulate rather than the one you happen to prefer.

Thresholds that trigger action

The score is continuous; the decisions are discrete. Bands turn a number into a routing rule.

Negative signals and disqualification

Disqualification isn't a low score - it's a hard gate that overrides the number. Conflating the two is a common design bug.

• Competitor domains: don't route a rival's eng team to a rep and don't waste enrichment budget on them.
• Students and .edu free-only intent: real users, wrong motion - keep them in product-led, out of sales.
• Personal-email tire-kickers with zero usage and no resolvable account.
• Explicit opt-outs and suppression lists, which must win against any positive score.

Closing the loop

A scoring model that never sees what happened next slowly drifts from reality. Feed outcomes back so the thresholds stay honest.

1. 1Capture outcomes. Join won/lost, meeting-booked and post-sale expansion back to the score each lead had at routing time.
2. 2Measure the bands. If the 40-74 nurture band converts as well as the 75+ band, your threshold is mis-set, not your reps.
3. 3Re-weight. Adjust point values (or retrain) on what actually predicted revenue and version the change so you can compare before and after.
4. 4Watch for drift. A signal that predicted fit last quarter can decay; re-check periodically rather than setting it and forgetting it.

Routing is where a scored lead becomes someone's job. Done well it's invisible. Done badly it drops leads, double-assigns or quietly sends every good account to the same rep.

This is core plumbing the role calls out by name - lead capture and routing logic, permissions, reliability. Treat it as a small distributed-systems problem, not a CRM workflow toggle.

Routing strategies

There's no single right strategy; you compose them. Most real systems layer ownership rules first and use round-robin only to break ties.

SLAs and escalation

Assignment without a clock is a wish. An SLA defines what "actioned" means and what happens when it isn't met.

1. 1Define the SLA. A 75+ lead gets a first touch within, say, 15 minutes during business hours. The number is the team's; the mechanism is yours.
2. 2Track the clock. Stamp assigned-at and first-touch-at, so the SLA is measurable and not a feeling.
3. 3Escalate on breach. No touch in time, reassign to a backup or notify a manager. The lead never just sits.
4. 4Surface it. A breach should page or post to a channel before a stakeholder notices the lead went cold.

Permissions and data access

Across startup, ecosystem and partnership programs, not everyone should see or act on every lead. Permissions are part of the routing design, not an afterthought bolted on later.

• Scope visibility by program and segment, so a partnerships lead isn't visible to the whole sales floor.
• Separate who can see a record from who can act on it; read access is cheaper to grant than write.
• Keep partner-sourced data walled appropriately when a data-sharing agreement requires it.
• Make permission grants data-driven (role + program membership), not hand-edited per user, so they scale with the team.

Fallbacks and dead-letter handling

Some leads won't route cleanly: no matching territory, ambiguous segment, a tie no rule breaks. Borrow the dead-letter queue from messaging systems - an unroutable lead goes somewhere visible, never nowhere.

Auditability

When a rep asks "why did I get this lead?" you need an answer in seconds. Log every decision the router makes.

{
  "lead_id": "ld_8f2a",
  "account_id": "ac_311",
  "score": 82,
  "band": "route_now",
  "strategy": "account_owner -> territory -> round_robin",
  "matched_rule": "account_owner",
  "assigned_to": "rep_kim",
  "sla_minutes": 15,
  "decided_at": "2026-06-15T14:03:22Z",
  "trace_id": "rt_5d9c"
}

The thing that separates a GTM Engineer from a marketing-ops admin is that you operate your pipelines like production software. Idempotency, retries, monitoring - the boring discipline that means a re-run doesn't email a prospect twice.

Cursor bars AI assistance in the craft screen specifically to see whether you reason about this yourself. Expect to defend why your design won't double-create records when a webhook fires twice, without hand-waving "the tool handles it."

Idempotency and retries

Networks retry, webhooks duplicate and a job that crashed mid-run will run again. The only safe assumption is at-least-once delivery, so every action has to be safe to repeat.

1. 1Derive an idempotency key. Hash the stable inputs (lead id + action type + day), so the same logical action produces the same key.
2. 2Check before you act. Has this key already succeeded? If yes, return the prior result instead of acting again.
3. 3Upsert, don't insert. Write keyed on the natural identity so a re-run updates rather than duplicates.
4. 4Make external sends idempotent too. Pass an idempotency token to the email/Slack API so a retry after a timeout doesn't double-message a prospect.

Rate limits, backoff and queueing

Third-party APIs throttle you and a burst of leads will hit those limits. Smooth the load instead of hammering through it.

• Queue work and drain it at each provider's allowed rate rather than firing the whole batch at once.
• On a 429, back off exponentially with jitter so a thundering herd of retries doesn't sync up and re-spike.
• Respect Retry-After headers when a provider tells you exactly when to come back.
• Set a sane max-retry ceiling, then dead-letter - infinite retries on a permanently failing call just burn budget.

Monitoring, alerting, runbooks

A silent GTM pipeline is a broken one nobody noticed yet. You want to catch a stall before a rep complains that the leads dried up.

Graceful degradation

When a provider is down, the pipeline should keep moving on what it has rather than freeze. Partial enrichment that scores and routes beats a stalled queue that delivers nothing.

Versioning and safe rollout

Changing live scoring or routing logic is changing a system reps depend on right now. Ship it like a code deploy, because it is one.

Now wire the parts together. A target company hits the pricing page; minutes later the right rep has a scored, enriched, personalized reason to reach out. This is the system you should be able to draw end-to-end on a whiteboard.

Treat this as the spine of a practical-round answer. Every concept from the earlier sections shows up exactly once, in order and you can name the tool at each step without making the tools the story.

The flow, step by step

1. 1Trigger + capture. A pricing-page visit fires an event (reverse-IP or a known cookie). Resolve the visitor's domain to an account or create one. This is identity resolution from Section 1, at the front door.
2. 2Enrich the domain. Run the waterfall against the account: firmographics, technographics and pull aggregate product usage from the warehouse. Cache hits skip the chain; misses fall through.
3. 3Find the right contacts. Identify people at the account by role - eng leadership, platform owners - and resolve them to contacts. A pricing-page hit from a 40-person eng org matters more than the visitor's individual title.
4. 4Score against ICP. Combine firmographic fit, technographic fit and live usage into a score and apply disqualification gates (competitor, student, suppressed).
5. 5Route the top contact. Send the highest-scoring eligible contact through the layered router (account owner first), attach the SLA and log the decision.
6. 6Trigger a personalized action. Generate outreach grounded in real context - what they use, why now - and send it idempotently so a retry never double-messages.
7. 7Instrument every step. Emit a structured event at trigger, enrich, score, route and send, all tied by one trace_id.

The architecture as components

The success metric

A system you can't measure is a system you can't defend in the data round. Pick one primary metric the flow is accountable for and name the guardrails that stop you from gaming it.

Generalize it into a primitive

The role wants durable infrastructure, not a one-off. The pricing-page flow is really a generic primitive - trigger → resolve → enrich → score → route → act → measure - and swapping the trigger and the action reuses everything in between.