How Air's GTM engineer built an outbound state machine on Knock2's visitor signal

Three reasons, in Tom's own terms

• More people identified. In Tom's comparison, Knock2 found significantly more people than RB2B.
• Filtering before delivery. Contacts are scored and filtered inside Knock2, so only good-fit visitors leave the platform.
• Webhooks into the stack Air already built. No new sequencer or dashboard, just data flowing into Air's own pipeline.

Stitched together by hand and hope

Tom Bonagura is the GTM engineer at Air. Like most teams, he started with no-code tables and automations, signal providers wired together column by column. In his words, it was “stitched together by hand and hope.” One small change could break three other things, and a failed step often failed silently.

Visitor data had the same problem. Air's RB2B feed went to a Slack channel Tom described as “a spammy channel that nobody really looks at.” A signal nobody acts on isn't a signal.

The signal at the top of the machine

Tom rebuilt outbound so every account enters at the top as a domain and moves through explicit states. Knock2 is one of the signals at that top: it identifies the companies and people visiting air.inc, scores them, and sends the ones worth working straight into Air's pipeline.

The filtering lives in Knock2, not in Air's code

Instead of receiving every visitor and writing the routing logic himself, Tom built a Play in Knock2: a standing rule that filters identified contacts by lead score and sends the segment that passes to a webhook.

That division of labour is what keeps the machine modular. Knock2 owns identification and fit. Air's engine owns the CRM gate, triage, enrichment, scoring and contact search. If Tom changes the score threshold, he edits one filter in Knock2 and nothing downstream needs to know.

Tom also liked a Knock2 feature he saw during setup: when someone from an account with an open opportunity visits the site, Knock2 can tag the opportunity owner in Slack. In his words: “Hey. Your person is essentially looking at the website right now.” It is the opposite of a channel nobody reads, because the alert goes to the one rep it matters to.

Inside Air's state machine

Like a package that is always ordered, shipped or delivered, every account in Air's pipeline is in exactly one state, and when something stops it, it is held with a reason and rechecked rather than lost. Each stage is its own module, so Tom can change one without breaking the rest.

Fast iterations, slow final decisions

Presenting the system at GTM as Code NYC, Tom reported that Air's meeting booking rate, accounts assigned to meetings booked, went from 1% to over 6%, and above 7% by the day of the talk, with the same team, the same list sizes and no change to the copy. That is the result of the whole system: Tom credits Air's reps too, and points to the scoring algorithm and how quickly the system lets him test changes.

New signals plug in at the top the same way Knock2 does, and any stage can be swapped, run live for a week and reverted. His rule for running GTM engineering: “Fast iterations. Slow final decisions.”