GTM workflows, written out step by step

The short answer

What a GTM workflow is

A GTM workflow is an automation that turns a signal into a sales or marketing action. Something happens, a system notices, it gathers enough context to decide whether it matters, and then it does something: assigns a lead, alerts a rep, starts a sequence, posts an update. The good ones also write down what happened, so you can tell later which signals were worth listening to.

Every recipe below has the same five beats: trigger, enrich, decide, act, log. The tools change. The beats don't. If you are new to the people who build these, start with what a GTM engineer is. For the tools named here, the GTM tools map sorts them by layer.

I'm not a GTM engineer. I'm a developer who built a tool that produces one of these signals, and I wrote these recipes from the tools' documentation and from wiring my own. Treat them as starting shapes, not as benchmarks.

Recipe 1

Inbound lead enrichment and routing

Trigger. A demo request or signup form is submitted.

Tools. A form tool, an enrichment source such as Clay or Apollo, the CRM, Slack.

1. Catch the form submission with a webhook, not a nightly export.
2. Enrich the email domain into company size, industry and location.
3. Score the account against your ICP with rules you can read, not a black box.
4. Check the CRM for an existing account owner before assigning anyone new.
5. Route to the owner, or round-robin if there is none, and post the summary in their Slack.

How it breaks. Free email domains enrich to nothing, so decide up front what a gmail.com signup gets. Duplicates appear when the CRM lookup runs after the create. Round-robin happily assigns leads to someone on vacation.

Recipe 2

Champion job change

Trigger. A past buyer or power user starts a new job.

Tools. A job-change signal from UserGems or Clay signals, the CRM, and a sequencer.

1. Keep a list of champions: contacts on won deals and heavy users of the product.
2. Recheck each one's current employer on a schedule.
3. When the employer changes, check the new company against your ICP.
4. Create the contact under the new account and tell the owner, with the old relationship attached.
5. Let the rep write the first message. Nobody wants a template from someone who knew them.

How it breaks. Profile data lags reality by weeks, so the alert can land after the person has already picked their tools. Contractors and people who update their headline for fun show up as false moves.

Recipe 3

High-intent website visit

Trigger. A known account views the pricing page or the docs for a paid feature.

Tools. A visitor identification tool such as RB2B or Warmly, the CRM, Slack. RB2B says its person-level identification is US only.

1. Resolve the visit to a company, and to a person only where your tool and the law allow it.
2. Ignore existing customers and your own staff before anything else.
3. Match the company to a CRM account and check its stage.
4. Alert the owner only on pages that mean something, such as pricing or a comparison page.
5. Cap alerts per account per week, or the channel gets muted.

How it breaks. Identification is a probability, not a fact, and it varies a lot by tool. Person-level identification has consent rules that differ by country and state. Alert fatigue kills this workflow faster than bad data does.

Recipe 4

Hiring signal to first line

Trigger. A target account posts a job for the team your product serves.

Tools. A job posting source, Clay or an LLM step for research, a sequencer.

1. Watch job postings at target accounts for the titles your buyers hire.
2. Pull the posting text and the company's recent news into one record.
3. Have a model write one sentence connecting the posting to the problem you solve.
4. Send that line to a person to approve before it goes into a sequence.
5. Log which postings turned into meetings, so the title list gets better.

How it breaks. Evergreen job posts never close and look like a fresh signal forever. A model-written first line that is wrong about the company is worse than no first line at all.

Recipe 5

Release to post to sales alert

Trigger. The product team merges a pull request that changes something a customer can see.

Tools. Merge & Tell for the release signal and the posts, a Slack channel, and whatever already runs your other workflows (n8n, Zapier, Make or Clay) for the CRM step.

1. Merge & Tell reads the merged PR and classifies it: what kind of change, whether a user can see it, and how big it is. Dependency bumps and refactors stop here.
2. For changes worth telling people about, it writes the posts and the changelog entry, and sends them to the networks your rules allow. A brand account can post on its own. A post in a person's voice waits for that person.
3. One of those networks can be a Slack channel. Point it at #shipped and sales reads the same announcement customers read, at the same time.
4. For the CRM side, your workflow tool asks the highlights API once a day for what shipped. The response carries the PR title, its kind and size, and copy already written about it. Ask for two days, not one, so a run that fails doesn't lose a day, and dedupe on pr_id so the overlap creates nothing twice.
5. Match each highlight to deals that asked for it, and create a task for the owner. The match is yours to build, because Merge & Tell does not read your CRM.
6. Before a rep writes to a buyer, check the feature is live for them. A merge is not a release if your team ships behind feature flags, on a release train, or to one region first.

curl -H "Authorization: Bearer $MERGETEL_TOKEN" \
  "https://merge.tel/api/v1/highlights?days=2&kinds=feature,improvement&min_magnitude=minor"

How it breaks. The classifier sometimes calls a big change minor. That is why the call above asks for min_magnitude=minor and lets the match decide. The match itself is fuzzy: a deal lost over "no SSO" has to find a PR titled "Add SAML single sign-on", which needs a keyword list or a label convention you keep. The closed-lost reactivation play builds this match out in full.

Sales is one audience for a release. Customers are the other, and the product updates guide covers telling them, channel by channel.

GTM automation

GTM automation that doesn't rot

GTM automation fails quietly, which is the worst way to fail. A workflow that stopped running looks exactly like a workflow with nothing to do. A few habits keep that from happening.

Log every run, including the empty ones. "Checked 40 accounts, 0 matched" is a line you want to see. A run that wrote nothing at all is a run you can't tell from a dead one.

Dedupe before you create. Every recipe here can create a CRM record. Look first, then create. Duplicates are the most common reason a sales team stops trusting an automation.

Keep a person on anything that speaks. Enrichment and routing can run alone. A message that goes to a human with your name on it should be read by one of yours first, at least until the numbers say otherwise.

Write down what each signal is worth. After a quarter, count which triggers became meetings. Kill the ones that didn't. A workflow nobody measures is a workflow that only ever grows.

Honesty

What these recipes skip

No numbers. I don't know your reply rates and I'm not going to invent a benchmark for them. These also skip the contract and compliance side: what your data vendor lets you store, what your email provider lets you send, and what consent visitor identification needs where your buyers live. Check those before you switch anything on. And Merge & Tell is only in recipe five. It has no CRM integration and sends no sales email, so the CRM and outreach steps everywhere on this page belong to other tools.