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.
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.
Bought on Monday, stale by Friday. Nothing in the system knows the difference, so nobody finds out until reply rates quietly halve.
Accounts enter on an event. Enrichment is a waterfall with a verification gate. Copy is generated per account from evidence in the database.
Discovery and scoring layers executed against live data. The account list on this page is the output, not a mock-up.
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.
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.
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.
Licensed domain-technology data confirms which Salesforce clouds are visible on the public surface. Confirmation only: never discovery. We measured the failure mode on a 1,065-domain pull: an unfiltered "runs Salesforce" query comes back roughly three-quarters retail and fashion, accurate about Commerce Cloud and useless for a buyer who sits in an internal platform team.
Built and tested, but not run for this cohort: our vendor balance ran out mid-build. No account on the list claims technographic confirmation as a result.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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: every account on this list was discovered from a live US Salesforce job requisition, 1,767 read from LinkedIn and 172 from ATS-restricted search across Workday, Greenhouse, Lever and iCIMS. The technographic layer is built and tested but contributed nothing to this cohort, so no row here claims technographic confirmation. Every score component is stored with the row, so any claim in an email can be traced back to the text it came from.
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.
The post-generation check rejects and regenerates on violation. A rule that is not tested is a rule that is not applied.
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.
flosum.comThree 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.
-all, DKIM 2048, DMARC stagedp=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.
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.
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.
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.
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.
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.
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.
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.
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.
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.