Playbook · For GTM Engineers

The stack is beautiful. Reply rates still cap at two percent.

Signals, enrichment, personalisation, automation. You have wired all of it. The one lever that moves conversion is whether the buyer knows anyone on your side, and today you do not have it as a column. Rudy ships as data: REST, MCP, webhooks.

Try for free Book a demo

POSThttps://hooks.yourco.com/boomerangwebhook · delivered 1.9s

{
  "type": "champion.job_change",
  "subject": "usr_2841",
  "from": "Recruiterflow", "to": "Vanta",
  "account": "acct_8123",
  "warm_score": { "before": 61.2, "after": 82.4 },
  "strongest_path": {
    "pillar": "customer", "hops": 1,
    "strength": 0.87
  }
}

Same data over the HTTP API, webhooks and MCP.

Co-owned goals

Three things you and Rudy both own.

Not three features. Three goals with a name on each, which is the difference between a tool you remember to open and a colleague who turns up.

01

Score

Make relationship strength a feature in the model rather than a thing sales talks about. It is deterministic, so you can A and B test the weight.

02

Route

Assign accounts by who has the strongest path, not only by territory. The rep who knows the buyer ramps the deal faster than the rep who does not.

03

Sequence

Branch the flows warm-first with cold as fallback. Nobody has to rebuild a cadence, they just stop being the only option.

Where Rudy shows up

Where the work already is. Not another tab.

You do not need Rudy in a UI. You need relationship strength as data: a column in the model, an event in the pipeline, a tool your agents can call.

1IN YOUR DATA

HTTP API and webhooks

Query paths per account or person, subscribe to events, and push outcomes back so the graph learns which routes actually convert.

POST/v1/asks/ask_5521/outcome202 Accepted

{ "outcome": "meeting_held",
  "opportunity_id": "opp_7710",
  "amount": 54000 }

Outcomes feed back into path strength.

2IN CLAUDE AND CHATGPT

Ask from wherever you think

The same graph as an MCP server, so Claude, ChatGPT or your own agents can call it.

ClaudeBOOMERANG MCP

add the warmest path and who should ask to every row of this table

C

Added three columns to 412 rows: warm_score, best_connector and hops. 147 rows clear 0.35.

NEXT

Branch the sequence on best_connector. Empty means cold.

boomerang.search_paths boomerang.rank_reach

3WHEN A SIGNAL LANDS

Pipe any signal into Slack

Post your own signals into a channel and Rudy answers each one in the thread with the route and the people to tag. No new UI for the team to learn.

# signalslive

Y

Your pipelineAPP6:00 AM

acct_8123 crossed fit 0.8 and intent 0.7.

1 reply

R

RudyAPPin thread

Vanta: one path, one hop. Dan worked with their platform lead.

@Dan Okafor close enough to ask?

Draft it Skip

Rudy drafts. A person sends. Every ask goes out from someone the recipient knows, and anyone along the way can say no.

Score

One more column in the feature set.

Rudy returns a deterministic score per account: same input, same output, timestamped, stable across versions. That is what makes it testable. You can hold everything else constant and find out what the relationship feature is actually worth in your model.

GET/v1/accounts/acct_8123/relationship200 OK · 84 ms

{
  "warm_score": 82.4,
  "strongest_path": {
    "pillar": "customer",
    "connector_id": "usr_2841",
    "target_id": "ct_9310",
    "strength": 0.87,
    "last_touch": "2026-08-12"
  },
  "paths_by_pillar": [ ... ],
  "rule_eligibility": {
    "can_ask_board": false,
    "reason": "ACV below threshold"
  },
  "freshness": "2026-08-27T06:00:12Z"
}

Same shape over REST, MCP and webhooks. Deterministic and idempotent.

Route

Assign by path strength, fall back to territory.

A new account arrives. Query the paths, rank the reps by who can actually reach the buyer, assign the top match, and fall back to territory rules when no path clears the threshold. The fallback is what makes it safe to ship on a Tuesday.

acct_8123CRM RECORD

DetailsRelatedContactsBoomerang

Rudy · rep match, ranked

DO

Dan OkaforWorked with their platform lead. strength 0.87.

0.87

SL

Sofia LindqvistShares two former colleagues at the account. strength 0.41.

0.41

JL

Jon LassiterTerritory owner. No path found.

Fallback

TH

ThresholdBelow 0.35 the router does not override territory.

0.35

Sequence

Warm first. Cold is the fallback, not the default.

Enrolment checks whether a path exists. If it does, Rudy drafts and the connector forwards. If it does not, the account drops to the cadence you already run. Nobody rebuilds anything; the cold flow just stops being the only flow.

ClaudeBOOMERANG MCP

how many accounts in this enrolment have a warm path

C

Of 412 enrolled, 147 have at least one path that clears your routing threshold. The rest drop to the standard cadence. Here is the branch split, and the one thing worth watching:

WORTH WATCHING

Sixty-one of the warm accounts route through the same nine connectors. If you do not cap per connector, this enrolment will burn them in a fortnight.

boomerang.search_paths boomerang.get_account boomerang.rank_reach

Route

Subscribe once. Stop polling.

Job changes, new executives, intros accepted, arriving as events rather than as something you have to go and check. Push outcomes back and the graph learns what actually converted, which is the part that compounds.

# gtm-engwebhook fired

R

RudyAPP10:41 AM

An intro on a tracked deal was accepted. Payload posted to your endpoint, and the outcome written to the opportunity before the rep opened it.

EVENT

TYPEintro.accepted

SUBJECTask_5521, Lena Park to Nadia Whitfield

EFFECTLogged to opp_7710 before the rep opened it

LATENCYDelivered in 1.9s, at-least-once

Open the payload Replay the event Edit the subscription

The trigger comes from your stack. Rudy does the relationship work.

Salesforce, HubSpot and Attio Clay Common Room and Outreach Your own calendars and call recordings

And he shows up where the work already happens.

Chrome, on LinkedIn and company websites Your team’s upcoming meetings, with Inside track Slack, including shared customer channels On the CRM record Claude and ChatGPT, over MCP HTTP API and webhooks

The rules Rudy keeps

Connector capital is a budget, not a tap.

Every pillar has a different cost and a different refill rate. The limits are set per source, and Rudy applies them before anything is surfaced, so the only asks anyone sees are the ones they are allowed to make.

Per pillar, as config

YESACV thresholds, qualification thresholds and frequency caps are readable through the API, so your router can respect them rather than guess.

NEVERHard-coding a threshold in your own code. It will drift from the CRM within a quarter.

rule_eligibility

YESEvery account response says which asks policy allows and why not when it does not. Branch on it.

NEVERSurfacing a path your own policy engine would have blocked.

Connector caps

YESReadable per connector. Respect them in enrolment or you will burn nine people in a fortnight.

NEVERTreating connectors as infinite. They are the scarcest input in the system.

Determinism

YESSame input, same score, timestamped. Which is what makes a controlled test of the feature weight possible.

NEVERNothing. This one is a guarantee, not a setting.

The connector contract

You will say yes or no to every ask. No silence.

Every connector agrees to one rule. Someone who ghosts three asks is telling you they would rather not be a connector, and that is a fine answer. Better than silence, because silence is what trains the next person to stop asking. Both sides protected.

YesNot nowWrong personI’d rather not

On the scoreboard