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

B ####

# gtm-eng4 members

R

RudyAPPFriday 4:58 PM

Four things this week. The scoring model change is the one that compounds, and it is about two days of work.

Add relationship_strength to the modelOne feature. Recalibrate w4 after.

Score

Route new accounts by path strengthTerritory becomes the fallback, not the rule.

Route

Branch the PG sequence warm-firstCold cadence still exists. It is just second.

Sequence

Subscribe to job-change webhooksChampion moves, in real time.

Score

Agree the planChange something

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.

The operating rhythm

A tool waits to be opened. A colleague has a standing agenda.

This is the part nobody else does. Rudy is not a stream of notifications you triage between calls. He works to a rhythm you both keep, and it produces something you can point at.

1ONCE A WEEK

☰This week’s planagreed Friday

Four things, in priority orderRudy proposes. You cut what does not belong.

Planned

Each one has a reason attachedNot a feed. A short list you both signed off.

Planned

Owner and date on every itemSo nothing is technically everyone’s job.

Planned

Anything you rejected stays rejectedHe does not quietly re-propose it on Tuesday.

Noted

2EACH MORNING

☰Today3 items

First item already movedSent 09:14. Reply came back before standup.

Done

Second needs your readDrafted and waiting. Two minutes of your time.

Now

Third is teed upEverything he needed is attached.

Today

3EACH EVENING

☰Closed outnothing dropped

Two closedOutcome logged against the record, not a spreadsheet.

Closed

One sent, no reply yetWhich is fine on day one. He will chase it.

Sent

One replannedSomething changed on the account. Reason attached, moved to next week.

Replanned

And then it repeats. Nothing carries over silently. Anything unfinished goes back into next week’s plan with a reason attached, which is why this survives a busy quarter instead of quietly stopping.

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_8123ACCOUNT

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 champion detections, network expansions, 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

Champion job change on a tracked account. Payload posted to your endpoint, and the account score recomputed before the rep opened the record.

EVENT

TYPEchampion.job_change

SUBJECTusr_2841, Recruiterflow to Vanta

EFFECTacct_8123 warm_score 61.2 to 82.4

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.

Slack On the account record Claude and Codex, over MCP REST 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