Analyst, GTM Systems

The GTM Systems Analyst is the individual contributor who administers the go-to-market / revenue systems stack and owns the integrity of the data inside it. The scope is the connected set of tools the revenue org runs on: the CRM as the system of record (accounts, contacts, leads, opportunities, the pipeline the number is reported from) plus the tools that write to it and read from it - marketing automation (MAP), sales engagement, CPQ, enrichment / data providers, and the reporting / BI layer. The core work is a loop: elicit requirements from the GTM stakeholders (sales, marketing, RevOps, customer success), translate them into declarative configuration inside the platforms (objects, fields, picklists, page layouts, record types, validation rules, in-platform flows / process automation, list views, and permission sets), maintain data hygiene and governance (dedup and merge, enrichment, field standards, required-field discipline), build and maintain reports and dashboards with metric definitions that hold up, run user support and enablement on the tools, and manage the request backlog and the system documentation. This is a practitioner / analyst seat, an individual contributor reporting to a RevOps or Sales Operations leader; it scales from a solo admin on one CRM to an analyst maintaining a multi-tool GTM stack, but the altitude is constant: elicit, configure declaratively, keep the data trustworthy, report accurately, document. It is deliberately not an engineering seat and not a strategy seat. The analyst works declaratively, inside the platforms' own configuration surface - it does not write custom code, stand up API-level integrations, or build data pipelines / iPaaS middleware; when a need requires those, it writes the requirement and hands it to the GTM Engineer. It serves the revenue strategy - it does not set the GTM process, own the forecast, or design territory / quota / comp; those are RevOps leadership's, and the analyst advises on what the system can support and implements the decision. What separates great from average is turning a stream of "can you just add a field / build a report" requests into a system that stays trustworthy and understandable: requirements elicited to the real need rather than the stated solution, configuration built and UAT-tested in a sandbox before it touches the system of record, data kept clean enough that a dashboard can be believed, reports whose metric definitions are pinned and reconciled, and documentation that leaves the next admin able to work the stack. A mediocre analyst rubber-stamps every request into a new field, edits production live, builds reports on dirty data, and leaves an undocumented tangle; a great one runs a change-managed, well-governed, documented system that the whole GTM org can trust the number from, and knows exactly which needs are declarative config, which are strategy calls to escalate, and which are code to hand to the engineer.