Go-To-Market Engineering · Proposal

You posted a role.
We built the system it describes.

Flosum's brief asks for a Go-To-Market Engineer to architect a programmatic outbound engine. Rather than describe how we would do that, we built it, ran the discovery layers, and brought the output: a scored target list of Salesforce accounts, each one entering on a dated, quotable signal.

Prepared 3 August 2026
Meeting Wednesday 20:00
Built by Momentum Nexus
·
Accounts scored
·
Tier A
·
Naming a rival tool
·
Compliance language
·
Live Salesforce reqs read
01 · The reframe

The brief describes a system, not a person

Read the responsibilities again: orchestration pipelines, waterfall enrichment, signal-triggered campaigns, sending infrastructure, LLM copy. That is seven layers of software. A contractor's output is hours. A system's output is a weekly cohort of accounts that entered on a dated signal, were enriched to a verified address, and were written to by a model that read their actual job req.

The second one keeps running when someone is on holiday. That is what we are proposing to build, hand over, and operate while your team learns it.

What most agencies ship

A list and a sequence

Bought on Monday, stale by Friday. Nothing in the system knows the difference, so nobody finds out until reply rates quietly halve.

What the brief asks for

Programmable commercial infrastructure

Accounts enter on an event. Enrichment is a waterfall with a verification gate. Copy is generated per account from evidence in the database.

What is in this deck

The system, already running

Discovery and scoring layers executed against live data. The account list on this page is the output, not a mock-up.

02 · Architecture

Seven layers, one store, every stage idempotent

Each layer is a separate script writing to a single SQLite store. Re-running a stage never duplicates rows, it only fills what is missing. That property is the whole reason this is safe to put on a cron and walk away from.

L0

ICP & signal definition

The entire commercial hypothesis lives in one YAML file: which roles count, what a competitor mention is worth, what Tier A means numerically. No ICP logic in Python, so a positioning change is a reviewable diff rather than a rewrite.

config.yaml
L1

Signal ingest

Accounts enter on an event with a date on it: an open Salesforce req. Two independent sources: LinkedIn reqs, and ATS-restricted search across Workday, Greenhouse, Lever and iCIMS where the employer is identified from the URL rather than guessed from a job title.

s1_signal_serp.py · s1b_signal_linkedin.py
L2

Technographic confirmation

Licensed domain-technology data confirms which Salesforce clouds are visible on the public surface. Confirmation only: never discovery. We measured the failure mode: an unfiltered "runs Salesforce" pull comes back three-quarters retail and fashion, accurate about Commerce Cloud and useless for Flosum.

s2_technographic.py
L3

Scoring & tiering

Score is a sum of observable facts, and the breakdown is stored per account. When a rep asks why something is Tier A, the answer is a list of quoted evidence. Any account that cannot produce a "why now" sentence does not get emailed.

s3_score.py
L4

Buying committee

Three contacts per account by title and seniority. Two motions kept separate: DevOps (VP/Dir Salesforce, Release Manager) and backup/security (CISO, VP IT). They do not share a definition of the problem, so they never share a sequence.

s4_contacts.py · runs on Flosum's Apollo seat
L5

Email waterfall

Provider 1 → 2 → 3, stopping at the first hit, then a verification gate. The 2% bounce ceiling is won by being willing to throw addresses away: "risky" and "unknown" are drops, not sends. That costs roughly 7% of the list and buys the only asset in cold email you cannot re-purchase.

s5_waterfall.py · runs on Flosum's verification seat
L6

AI copy, per account

The model gets the account's why-now, a verbatim slice of the real req, the detected stack and the contact's title, and is forbidden from introducing a fact that is not in that payload. Style rules are enforced twice: in the prompt, and again as a post-check that rejects and regenerates.

s6_copy.py
L7

Activation & feedback

Leads are staged into a paused campaign. The pipeline never presses send. Replies and bounces are written back, and the weights that correlate with positive replies are raised in the next cohort. Three cohorts in, the numbers stop being our judgement and start being your data.

s7_activate.py · dry-run by default

Layers marked in green ran to produce this deck. L4, L5 and L7 are built and dry-run tested, and deliberately point at Flosum's own vendor accounts: the sending reputation and the enrichment credits should belong to Flosum from day one, not to an agency.

03 · Signal taxonomy

Why an open req beats every intent product on the market

"Has Salesforce" is not a signal. Roughly 150,000 companies have Salesforce and most of them will never need release management. An open Salesforce Release Manager req is a different thing entirely: it is technographic proof, a maturity filter and a timing signal in one observable fact. You do not fund that role unless releases already hurt.

Tier 1 · entry

An account cannot enter without one

  • Release Manager / DevOps req: someone owns releases full-time
  • Platform Manager / Architect req: enough surface area to need architecture
  • Admin / Developer req: weakest entry signal, scored low on purpose
Tier 2 · amplifiers

Where the highest-value accounts come from

  • Copado / Gearset / AutoRABIT named in the req: category already bought, budget exists, incumbent exists. Shortest cycle on the list.
  • "DevOps Center": on the free tool, at or near its ceiling
  • "change sets": no tooling at all; real, unmanaged pain
  • SOX / HIPAA / FedRAMP / GxP: native architecture stops being a feature and becomes the reason to switch
  • Multiple reqs open at once: the best external proxy for org load
Tier 3 · confirmation

Scores an account, never sources one

  • Salesforce clouds detected on the public domain
  • Regulated vertical from the employer's sector
  • Enterprise stack co-signals (Workday, ServiceNow, Okta)
Anti-signals

What we take out, and why it matters

Consultancies and staffing firms are one of the largest blocks in any pull of US Salesforce reqs. A systems integrator hiring a Salesforce architect is staffing a client project, not running an org that needs release management. They are a partner channel, not an ICP account. Leaving them in produces a target list that looks full and converts near zero, so the pipeline flags and removes them: the count is shown on the account explorer.

Deliberately excluded

Things we did not use

  • Bidstream intent data. Unattributable. You cannot tell a prospect why you emailed them without either lying or admitting you bought their browsing behaviour.
  • Funding announcements. Real signal for many products, weak for this one. A Series C does not change how often you deploy.
  • Install-base lists. Stale, cannot tell a 20-user org from a 5,000-user org, and contain no timing.
Scoring

Every point traces to a quotable string

  • Role weight (strongest open req) · 8–30
  • Competitor or tooling mention · 4–40
  • Compliance vocabulary · 8–18
  • Hiring heat (extra open reqs) · 0–30
  • Technographic breadth · 0–38
  • Vertical fit · 4–20

Tier A at 70+, Tier B at 45+. Only Tier A is activated in week one; Tier B is held until the first cohort's reply data has recalibrated the weights.

04 · Proof

The target list, and how every account got there

Below is the top of the scored list. Each row entered because of a specific live Salesforce req, and each one carries the evidence that produced its score. The full set, with filters by tier, vertical and competitor tool, is on the account explorer.

# Company Vertical Reqs Signal that put them on the list Score Tier
Loading account data…

Source note: accounts were discovered from live US Salesforce job requisitions and confirmed against licensed domain-technology data. Every score component is stored with the row, so any claim in an email can be traced back to the text it came from.

05 · AI-native copy

Generated per account, from evidence in the database

Not per segment, not per persona with merge fields. The model receives only what the pipeline observed about that one account and is explicitly forbidden from introducing a fact that is not in the payload. No invented metrics, no "companies like yours saw 40%". If there is no number, there is no number.

Enforced twice

Style rules that are actually tested

  • Under 90 words a step, step one under 70
  • First sentence references their specific signal, not their greatness
  • A named competitor is mentioned once, neutrally: they chose it
  • No em dashes, no "I hope this finds you well", no "quick question"
  • Step one asks a question, not for a meeting

The post-generation check rejects and regenerates on violation. A rule that is not tested is a rule that is not applied.

Step 1 · to Director, Salesforce Platform · generated from the account's own req
Loading a generated sample…
06 · Infrastructure

The 2% ceiling is a refusal, not a setting

Hard bounces are not fixed at the verifier. They are fixed by being willing to discard addresses that do not verify cleanly, and accepting the volume loss. Three enforcement points, not one.

Domains

Never flosum.com

Three dedicated sending domains, three mailboxes each, named after real people rather than sales@. Each redirects to the main site, so a recipient who checks finds something real. The corporate domain carries your trials, invoices and renewals; one bad campaign puts all of it in spam with no undo.

Authentication

SPF -all, DKIM 2048, DMARC staged

p=none for four weeks while the aggregate reports are read, then p=quarantine. Going straight to quarantine on a fresh domain hides the failures you needed to see.

Warmup

Three to four weeks, no exceptions

Ramping to 30 sends per mailbox per day, and warmup stays on permanently at a reduced rate afterwards. Switching it off after ramp is the usual reason a domain that was fine for two months suddenly is not.

Bounce control

Halt at 1.5%, not 2%

Verification gate before send, daily stats read during send, and a suppression list after, so a bounced address is never bought a second time. Catch-all addresses require two independent providers returning the same address.

Ceiling

~270/day, ~5,700/month

More than this ICP can absorb, which is the point. The constraint on this engine is signal quality, not capacity, so there is never a reason to push volume into the red.

Hard rule

A human presses send

The pipeline stages leads into a paused campaign and stops. An unreviewed sequence landing in a Tier A account is not a recoverable error: you do not get a second first email to a VP of Platform.

07 · Engagement

What happens in the first ninety days

Week 1

Accounts and infrastructure in parallel

ICP and scoring weights signed off against the list in this deck. Sending domains bought, DNS set, warmup started the same week: it is the long pole and nothing else depends on it.

Weeks 2–3

Enrichment and committee

Pipeline re-pointed at Flosum's own Apollo, verification and Apify seats. Buying committees built for Tier A, waterfall run, match rate measured against the 90% target rather than assumed.

Week 4

Copy, review, first cohort

Per-account sequences generated for both motions and reviewed by Flosum line by line. First cohort goes out at low volume off warm domains. Nothing is sent that a human has not read.

Weeks 5–8

Feedback loop closes

Replies and bounces written back to the store. Score components that correlate with positive replies get raised, the rest get lowered. Tier B opens once the weights have moved once on real data.

Weeks 9–12

Handover

Repo, cron and runbooks move to Flosum's infrastructure. Your team runs a cohort with us watching, then one without. Everything already sits on your accounts, so nothing has to be re-pointed at the end.

What we need from Flosum
  • ICP and scoring weight sign-off
  • Vendor seats in Flosum's name: sender, Apollo, verification, Apify, DataForSEO
  • Budget approval for three sending domains
  • One reviewer for copy, once per cohort
  • Salesforce as CRM of record for reply sync
What you own at the end
  • The repo, the config, the store and the cron
  • Every sending domain and its reputation
  • Scoring weights calibrated on your own reply data
  • Runbooks for deliverability, signals and recalibration