Automation that still works on Monday morning.
We build the enrichment, deduplication, routing, scoring and outbound workflows your revenue team runs on — in whichever tool fits the job, wired into whichever CRM you use.
Every workflow ships with an owner, an error path and a dashboard. When something breaks, you know which step failed and why.
Why automations break
Most automation problems are not tool problems.
Silent failure
A rate-limited step errors and the run is marked done. Nothing alerts; the record is simply never enriched.
Duplicates on re-run
No upsert key, so the same lead lands twice. That is how a clean CRM becomes unreportable.
Cost scales, logic doesn’t
Per-task pricing meets enrichment volume. The bill grows with records while the workflow stays the same.
No version, no rollback
Someone edits a live flow on Friday. No diff, no review — only the symptom on Monday.
What we actually build
Six workflow families, built to be maintained.
Most of it runs straight through. A person only sits in the loop where a wrong action would cost you a customer or a domain.
Enrichment waterfalls
Provider order by cost and hit rate, cached results, coverage reported per field rather than per vendor.
Deduplication & data hygiene
Matching rules, merge policy and a quarantine list. Automatic on clear matches, queued for review when the merge is ambiguous.
Lead routing & SLA enforcement
Territory, round-robin and capacity rules with measured time-to-first-touch and an escalation path. Runs untouched.
Scoring & pipeline risk
Fit and intent scored separately, recomputed on signal, with the inputs visible on the record so reps can argue with the number.
Outbound & AI drafting — with a review queue
This is the one place we insist on a person: anything that leaves your domain gets accepted, edited or rejected first. Everything up to the send is automatic.
This is the Signal engine in full →Observability & alerting
Run logs, failure alerts in Slack, and a data-quality dashboard that names the broken step instead of the broken feeling.
Approval belongs where being wrong is expensive: outbound messages, merges, deletions, anything customer-facing. Routing, scoring, syncing and enrichment run without anyone watching — that is the point of automating them.
How we pick the tool
Clay, n8n, Make, Zapier or Python
Each one is right somewhere. We choose per workflow, not per vendor relationship — and we will happily keep what already works.
Source: RevPack build log 2025–2026 · Method: per-workflow selection · Vendor limits re-checked per engagement
Automation across CRMs
Every CRM automates differently. That is most of the job.
The logic stays portable. What changes is the write step — object model, API budget, what the native engine can see, and what happens when the same record arrives twice.
What can be represented
Custom objects, associations and required fields differ per CRM and per tier. One object here is three objects there.
Rate limits shape design
Caps and bulk endpoints decide batch versus record-by-record. Ignore them and it works in testing, dies at volume.
What stays in the CRM
Some logic must stay where admins can own it. Some has to move out for branching, retries or external calls.
What a second write does
Upsert keys, merge behaviour and whether history survives. This one difference makes a re-run harmless or harmful.
Changing CRM does not mean rebuilding the automation. Because the logic sits outside the CRM, a migration replaces the write step and the field map — not the workflows.
See CRM Implementation & Migration →Selected work
What we rebuilt, and why
Enrichment and routing, rebuilt
Waterfall enrichment replaced single-provider lookups; routing moved out of native workflows into a logged, retried pipeline.
Deduplication and CRM hygiene
Matching and merge policy written down first, then automated — with only ambiguous merges left for a person.
Signal-driven outbound
Intent signals collected into one log, drafts generated per signal, every send approved by a rep before it left.
Numbers for these engagements are withheld pending client clearance. We publish a figure only with approval, the sample size and the method — ask on the call and we will walk you through them.
How we start
Proof of concept first. Retainer only if it worked.
Automation audit
Every existing automation listed with what it touches, what it costs and how it fails. You keep the document either way.
Proof of concept
One workflow, built properly, in production, with its error path and dashboard. Scoped in hours, not phases.
Retainer or fractional GTM engineering
Ongoing build and maintenance, or an engineer inside your team using your tooling and your review process.
Scope and cost are quoted after the audit, against your stack — we would rather give you a real number than a published one.
The written record
Read two and judge the reasoning
Each of these is a worked problem, not a listicle.
Questions we get asked
GTM automation, answered.
Does everything need a human to approve it?
No. Routing, scoring, enrichment and syncing run straight through — that is the point of automating them. We put a person in the loop only where a wrong action is expensive: outbound messages, merges, deletions and anything customer-facing.
Is Clay better than Zapier for GTM automation?
For enrichment and research, yes — Clay runs provider waterfalls natively. For orchestration with retries and version control, neither is the answer: that belongs in n8n, Make or code. Zapier stays useful for small, low-risk glue.
We already run Zapier and Make. Will you rip them out?
Only where they are the reason something breaks. The audit lists each automation and says migrate, rewrite or leave alone — plenty stay exactly as they are.
What does GTM automation cost?
It depends on how many workflows you run and how broken they are, so we scope it after the audit rather than publishing a number. Tool subscriptions and LLM usage are billed by the vendor, not by us.
Can our team maintain this after you leave?
That is the delivery standard: exported and documented workflows, an owner per workflow, and a runbook with the failure modes. We hand over, then stay available on retainer if you want us to.
Start with an audit of the automations you already run.
Two weeks, fixed scope. You leave with every automation documented, the failure modes named and a prioritised build order — whether or not you build it with us.