GTM engineering agency for outbound that runs itself
GrowthPal is a B2B outbound and GTM engineering agency operated by Inferno Media, LLC, working from Kathmandu, Nepal.
Last reviewed 29 October 2026
A GTM engineering agency builds the data and workflow layer underneath outbound: the enrichment waterfall that resolves records, the orchestration that moves them, and the routing that handles every reply state. Go to market engineering is the systems half of outbound, and this page writes out the two parts nobody else publishes, the waterfall as a decision procedure and the reply router as a state machine.
When a GTM engineering agency earns its place
Who this is for
- The motion works and the plumbing does not. You know who to target and what to say, and the system loses records between the database, the sequencer and the CRM. That is an engineering problem with an engineering answer.
- You are paying for enrichment and cannot say what it bought. Credits go out, records come back, and nobody can state the verified hit rate per provider on your own list. That number is measurable and it usually changes the stack.
- Replies arrive and nothing happens for a day. An interested reply that waits overnight while a follow-up fires at the same person is the most expensive bug in outbound, and it is a routing fault rather than a staffing one.
- You want to own the build. Tables, workflows, credentials, documentation and a runbook, handed over on a named date, so the system keeps running whether or not we do.
Who this is not for
- There is no motion to engineer yet. If nobody has sent a campaign and learned anything, automation will produce the wrong thing faster. Run the manual version first, badly, and engineer what survives.
- You want a tool recommendation. The stack follows from the measurements, not the other way round. A list of tools without the hit rates behind them is worth about what it costs.
- You want records at any cost. We will not construct an address from a naming pattern and call it found. An unverified guess is a bounce, and bounces move a sending domain toward the thresholds the mailbox providers publish.
- The build depends on breaking somebody's terms. If the only way to get the data is a method a platform's user agreement prohibits, we will say so and propose a different route rather than quietly building it.
What a build covers
| Component | What is done | What the client receives | Who owns it at the end |
|---|---|---|---|
| Data model | Define the account and person objects, the fields that drive decisions, and which system is authoritative for each one, before any workflow is built. | A written schema with an owner per field. | Client |
| Enrichment waterfall | Order the providers by verified hit rate per unit cost on a sample of your own list, set the advance condition on failed verification rather than on an empty response, and define what happens to records nobody resolves. | A running waterfall with per provider attempts, returns, verified and cost per verified record. | Client |
| Orchestration | Build the movement between systems in whichever layer is right for each job: the enrichment tool for record level work, an orchestrator for cross system flows, and code where neither fits. | Workflows in your own accounts, documented, with the reasoning for each placement. | Client |
| Reply routing | Classify every inbound reply into the states that actually occur, write a disposition back to the CRM for each, and let suppression win when a message carries two states at once. | A router with a review queue and a confidence score per classification. | Client |
| Suppression layer | One suppression store that every sequence, sending domain and list reads from, honoring opt outs expressed in words as well as through a link. | A single suppression source of truth, not a per campaign list. | Client |
| Measurement | Define each reported term in writing, including what is excluded from each denominator, then build the reporting on those definitions. | A reporting view whose numbers can be recomputed from the raw data. | Client |
| Permission review | Check that the data route the build depends on is one the provider's terms and the platform's user agreement actually allow, before it is built rather than after. | A written note of what is permitted under whose entitlement, and where the alternative route was taken. | Client |
| Handover | Transfer the tables, the workflows, the credentials, the documentation and a runbook on a named date, with a walkthrough for the person who will own it. | The full artefact list, in your accounts, with a named owner against each. | Client |
How a build runs
Map what exists
Map which systems hold which fields, where records enter, where they leave, and where they currently get lost. Most engagements find at least one place where a field is written by two systems that disagree.
What you provide. Read access to the CRM, the sequencer, the enrichment tool and anything in between.
Sample before buying
Take a few hundred records from your actual target segment and run every candidate provider against them. Published coverage is an average across a whole database, and what matters is the hit rate on your geography, company size and seniority band.
What you provide. A representative sample of the segment, including the parts you expect to be hard.
Order the waterfall from the measurement
Providers are ranked by verified hit rate per unit cost on that sample, descending. Not by list price, not by reputation. The order is a finding about your segment and it does not transfer to the next client.
What you provide. A decision on the budget envelope per found record, which sets where the stack stops.
Build the advance and fallback logic
The waterfall advances when a provider returns nothing or returns something that fails verification. Fallbacks change the question rather than asking the same one again: a different identifier, a different person at the same account, or a different channel.
What you provide. Approval of the fallback rules, especially reassigning a record to a colleague.
Build the router and the suppression layer
Every reply state gets a defined action, a disposition written back, and a confidence threshold below which a human looks first. Suppression is built once and read everywhere.
What you provide. Who takes interested replies, and how fast you want them routed.
Define the measurements in writing
Reply rate, positive reply rate, meeting booked and meeting held are four different numbers and most reporting blurs at least two of them. Each gets a written definition including what is excluded from the denominator.
What you provide. Sign off on the definitions, because they are what everyone will argue about later.
Run it, instrument it, then tune
The first weeks produce the per provider numbers that the initial order was only a hypothesis about. Providers with a good hit rate but no unique contribution come out. The order is re-measured on a schedule, because coverage drifts.
What you provide. Time from whoever owns the data, to review the first provider numbers when they land.
Hand it over
Tables, workflows, credentials, documentation, runbook, and a walkthrough with whoever owns it next. The handover is a date in the plan, not a promise in the proposal.
What you provide. A named person to receive it.
The enrichment waterfall, written out as logic
Across ten pages competing to be your GTM engineering agency, go to market engineering spelled either way, nine name the tools and none states the ordering rule, the per provider hit rate, the cost per record actually found, or what happens to a record nobody resolves. The vendor documentation does not state the advance condition either. Here is the procedure, which is the part worth buying.
A waterfall is an ordered list of providers all asked the same single question about the same record. Usually that question is what this person's work email address is, but the structure is identical for a direct dial, a headcount, a funding round or a technology in use. The defining property is that the providers are interchangeable answers to one question. If two steps answer different questions, that is a pipeline and not a waterfall, and calling it one hides the fact that nobody is measuring either step.
The advance condition is the part nobody publishes
A waterfall advances when the current provider returns nothing, or returns something that fails a validation test. Those are different failures and treating them the same is the most common fault we find. A waterfall that advances only on an empty response stops at the first provider confident enough to return a bad address. A waterfall that advances on a failed verification keeps going. Verification is therefore inside the waterfall's logic, not a stage bolted on at the end.
What decides the order
- Hit rate on your segment, not in general. A published coverage figure is an average across a whole database. A provider resolving most mid-market records in one market may resolve a quarter of early-stage records in another. First position goes to whoever measures best on your actual list.
- Cost per found record, not cost per call. A provider costing twice as much per call but hitting three times as often is cheaper. Only the second number affects your spend.
- Survival through verification. A cheap provider with a high raw return rate and a low verified rate is actively harmful at the top of a stack, because it ends the cascade with answers that later bounce.
The rule that falls out of those three: order by verified hit rate per unit cost, descending, measured on a sample of your own list. Each provider after the first is only called on the records the earlier ones failed, so each costs less in total and adds less coverage than the one before it. The marginal economics get worse at every position, and the decision at each one is the same. At some depth the next provider is resolving a handful of records at many times the cost of position one, and the right answer is to stop and route those records elsewhere rather than add another provider.
The four numbers to report per provider
| Number | What it is | Why it is reported this way |
|---|---|---|
| Attempts | Records that actually reached this provider | The denominator shrinks at every position, so position four's hit rate cannot be compared to position one's unless the attempts are shown next to it |
| Returns | Attempts where the provider gave an answer | Raw return rate is what vendors publish and it is the least useful of the four |
| Verified | Returns that survived verification | This is the only count that becomes a usable record |
| Cost per verified record | Spend at this position divided by verified | The number that decides whether the position stays in the stack |
Two derived views are worth sending a client. Unique contribution asks how many of the records a provider verified would have been found anyway further down the stack: a provider with a good hit rate and near zero unique contribution is a duplicate, usually sitting above something that covers everything it covers. Re-test cadence matters because coverage drifts, so the order is re-measured on a schedule rather than set once and inherited forever.
What happens to a record nobody resolves
- Re-queue with a changed key. The record failed as asked, not necessarily as answerable. It goes back through a fallback with a different identifier, once, not in a loop.
- Re-queue on a delay. Provider coverage refreshes, so a record that fails today can be retried in a month or two, which is cheap because the population is small by then.
- Route to a different motion. No email found does not mean no account. The account can go somewhere that does not need a personal address.
- Marked unresolved and excluded, with the reason recorded, counted and reported.
- What must never happen is guessing. A pattern-constructed address, a first initial and a surname at the domain, is not a found record. It is an unverified guess that bounces, and bounces move a sending domain toward the spam rate ceilings the mailbox providers publish.
The honest headline for a waterfall is not coverage. It is verified coverage at a stated cost per verified record on a stated segment, plus the count of unresolved records and what happened to them. A coverage number quoted without a denominator, a verification standard and a segment is not a measurement.
Outbound sales automation: the reply router as a state machine
Reply routing is the second half of the build and the half that is missing from every agency page we examined. A sequencer sends. A router decides what happens when somebody answers, and the states below are the ones that actually occur.
| Reply state | What the workflow must do | The failure mode it prevents |
|---|---|---|
| Out of office | Pause rather than stop. Read the return date from the body where one is stated and resume on it. Never count it as a reply in any metric. Extract the named alternate contact, because an out of office that names a colleague is a referral in disguise. | Reply rate becomes meaningless once automatic responses are counted in it |
| Referral to a colleague | Extract the referred person, create or match the record, link it to the original thread so the referral is visible as the reason for contact, give the original contact its own correct disposition, and open the new conversation naming the referrer. | A referral used badly burns two relationships at once, which is why this state goes to human review before sending |
| Unsubscribe | Write to the suppression layer first and log second, across every sequence, sending domain and list, permanently. Honor it when expressed in words, because people type take me off this list far more often than they click. | A suppression written to one campaign instead of the suppression layer, which is how someone gets emailed again from a different domain |
| Interested | Route to a named human inside a defined window, with the full thread, the enrichment that caused the targeting and the reason for contact attached, and remove the record from every other active sequence in the same moment. | A positive reply followed an hour later by a scheduled follow-up that contradicts it |
| Not now | Extract or infer the date, suppress all sending until then, and re-queue. It is a scheduling task, not a loss. | Treating a deferral as a rejection throws away the cheapest future pipeline in the system |
| Wrong person | Separate the two cases. Wrong role at the right company is a targeting fix and the next step is the right role at that account. Wrong company, or a person who has left, is a stale record and the fix belongs upstream in the data layer. | Collapsing both into one state means the enrichment that produced the bad record never gets corrected |
- One message can carry two states. Not me, speak to someone else, and take me off your list is a referral and an unsubscribe at once. The classifier has to return more than one label and suppression has to win.
- Every state needs a confidence score and a review queue, because a confidently wrong automated reply to a real objection costs the account.
- Every state writes a disposition back to the CRM, or the sending tool and the CRM disagree about what happened and the reporting becomes fiction.
- The set of states is the measurement model. A positive reply rate only means something once out of office is out of the denominator and unsubscribes are counted somewhere.
Permission, which no competing page mentions
- Platform user agreements. The professional network most of this market quietly depends on prohibits members from developing, supporting or using software, devices, scripts, robots or other means to scrape or copy its services, including profiles and other data, and separately prohibits using bots or other unauthorized automated methods to access it. A build that depends on that is selling a client a breach of terms they already agreed to.
- Data provider redistribution terms. At least one major provider's terms prohibit distributing, selling or licensing business contact information to third parties, and restrict access to authorized users of the account. An agency enriching inside its own seat and handing the file to a client is a redistribution question, not a workflow question. We enrich under the client's own entitlements and say so.
- Notice for data not obtained from the person. Where personal data was not obtained from the individual, what is owed includes the source of the data and whether it came from a publicly accessible source, and the deadline is the earlier of one month, the first communication, or first disclosure. For outbound that means the obligation lands at the first email, not later.
- Automated decisions about people. A person has the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them. Whether a given lead score crosses that line is a legal judgement rather than a settled fact, which is exactly why a human stays in the loop at the points where the system decides something about a person.
- Sending requirements. Above 5,000 messages a day to one major provider's users, SPF, DKIM and DMARC are required, marketing mail must support one click unsubscribe, and the published spam rate requirement is below 0.30 percent with separate guidance to stay below 0.10 percent. The lower figure is what an operator should design to.
One number we will not repeat
The figures circulating for how many agencies use a particular enrichment tool come from a single industry survey. The pages repeating it disagree with each other on the sample size, the period and the headline number, which has been published as both 96 percent and 69 percent from what is said to be the same sample, and the report itself was not readable at source. We have left it out. In a market where everyone repeats the number without checking it, saying that is worth more than the number.
What to ask a GTM engineering agency before signing
The work is invisible until it breaks, which makes it easy to sell badly. These questions surface whether anyone is measuring.
| What to check | The question to ask | What a good answer looks like |
|---|---|---|
| Waterfall order | How will you decide the order of the providers? | From a sample of our own list, ranked by verified hit rate per unit cost. An order quoted before anyone has run a sample is a template. |
| The advance condition | When does the waterfall move to the next provider? | On nothing returned or on a returned answer that fails verification. If the answer is only the first, the stack will stop at the first confident wrong answer. |
| Unresolved records | What happens to a record no provider resolves? | A named destination: re-queued with a different key, re-queued later, routed to another motion, or marked unresolved and reported. If the answer involves constructing the address from a pattern, walk away. |
| Permission | Which parts of this depend on a platform's data, and what do their terms say? | A straight answer, including where an alternative route was chosen because the direct one was not permitted. Silence here is the risk being moved onto you. |
| Reply states | List the reply states the router handles and what each one does. | At least out of office, referral, unsubscribe, interested, not now and wrong person, with suppression winning when a message carries two. |
| Handover artefacts | Name everything we receive at the end and the date we receive it. | Tables, workflows, credentials, documentation and a runbook, on a date in the plan. Most pages promise ownership and none lists what that means. |
What we can show you for build work
| What GrowthPal has published | What it counts | |
|---|---|---|
| 4M+ cold emails sent for 40+ B2B companies, across Prabesh Khanal's five years of outbound work, including campaigns led before GrowthPal was founded in 2025 | Emails sent, cumulative across every engagement in the founder's career. Not one campaign, not an average, and not confined to GrowthPal. | Source |
| The interested-reply definition and counting rules | Not a figure. A link to the published methodology. | Source |
What stands behind the build
- No build-only case study is published yet. GrowthPal has not published a standalone GTM engineering outcome, so there is no before and after to point you at for this service in isolation. The figures above cover outbound work as a whole and are defined on the glossary page.
- The measurement model comes before the build. Every term that appears in reporting is defined in writing first, including what is excluded from each denominator. That is the difference between a number you can recompute and a number you have to believe.
- Provider performance is measured on your list. Attempts, returns, verified and cost per verified record, per provider, per segment, recomputed on a schedule. If a provider is a duplicate of one below it, that is visible in your own data rather than argued about.
- The terms are checked before the build, not after. Where a data route depends on something a platform's user agreement or a provider's terms prohibit, we say so and propose another route. The sources for that are cited at the foot of this page.
Questions about GTM engineering work
What does a GTM engineer actually do that a sales ops person does not?
The overlap is large and the difference is where the work points. Sales operations tends to keep an existing system correct and reportable. This work builds the system that acquires and resolves records in the first place: the enrichment logic, the orchestration between tools, the routing of replies, and the measurement model underneath all of it. A GTM engineering agency is bought for the first of those. In a small company one person does both. In a bigger one they argue about field ownership, which is why the data model gets written down first.
Do we have to use one particular enrichment tool?
No, and the order of providers inside it matters more than which tool wraps them. The honest position is that the tool is a convenience layer over a set of providers, and the value is in which providers are called, in what order, with what advance condition. We will tell you when a workflow belongs in the enrichment tool, when it belongs in an orchestrator, and when it belongs in code, with the reason for each.
How do you measure whether the waterfall is working?
Four numbers per provider, per segment: attempts, returns, verified, and cost per verified record. Plus unique contribution, which asks how many of a provider's verified records would have been found anyway by something further down. A provider with a good hit rate and no unique contribution is a duplicate and comes out of the stack.
What happens to records that nothing resolves?
Unresolved records get an explicit destination rather than disappearing. Re-queued with a different identifier, re-queued on a delay because provider coverage refreshes, routed to a motion that does not need a personal email address, or marked unresolved and reported with the reason. What does not happen is constructing an address from a naming pattern, because that is a guess that bounces and bounces are what damage a sending domain.
Is scraping part of this?
Not of what we build. The user agreement of the professional network this market leans on prohibits using software, scripts or bots to scrape or copy its services, including profile data. Where a build would depend on that, we say so and route around it. You are the one who agreed to those terms, so the risk of ignoring them lands on you rather than on the agency that suggested it.
Who owns the build at the end?
You do, and the handover is a dated step with a list attached: the tables, the workflows, the credentials, the documentation and a runbook, walked through with whoever owns it next. Several pages in this market promise ownership. The useful question is which artefacts, on what date.
Can you run it as well as build it?
Yes. Build and run are separate decisions and plenty of clients take the build and run it themselves. Where we run it, the same reporting goes to you, and the handover list exists from the start rather than being assembled when the engagement ends.
How does reply routing differ from a shared inbox?
A shared inbox shows you the replies. A router classifies each one into a state, acts on it, and writes a disposition back to the CRM. The states that matter are out of office, referral, unsubscribe, interested, not now and wrong person, and the hard part is that one message can be two of them at once. When that happens, suppression wins.
How long does a build take?
The honest answer is that it depends on how many systems hold authoritative fields and how clean the CRM is, and anyone quoting a duration before seeing that is guessing. What is fixed is the order: map what exists, sample the providers, order the waterfall from the measurement, then build. The sampling step is short and it is what makes every later estimate real.
Do you work alongside our existing agency or team?
Often. The build is the layer underneath whoever is running the campaigns, and the reporting definitions are written so that two teams reading the same dashboard mean the same thing by reply rate. That alone resolves most of the arguments between an in-house team and an agency.
Sources
- User Agreement, section 8.2, LinkedIn Corporation, effective 3 November 2025. https://www.linkedin.com/legal/user-agreement. Accessed 29 October 2026.
- Terms of Service, general usage and business contact information restrictions, Apollo.io, last updated 10 August 2026. https://www.apollo.io/terms. Accessed 29 October 2026.
- Regulation (EU) 2016/679, Article 14, information to be provided where personal data have not been obtained from the data subject, Publications Office of the European Union, 27 April 2016, OJ L 119. https://publications.europa.eu/resource/cellar/3e485e15-11bd-11e6-ba9a-01aa75ed71a1.0006.02/DOC_2. Accessed 29 October 2026.
- Regulation (EU) 2016/679, Article 22, automated individual decision-making including profiling, Publications Office of the European Union, 27 April 2016, OJ L 119. https://publications.europa.eu/resource/cellar/3e485e15-11bd-11e6-ba9a-01aa75ed71a1.0006.02/DOC_2. Accessed 29 October 2026.
- Email sender guidelines, Google, Gmail Help, no publication date displayed by the publisher. https://support.google.com/mail/answer/81126. Accessed 29 October 2026.
- Building a data waterfall, Clay University documentation, no publication date displayed. https://university.clay.com/docs/building-a-data-waterfall. Accessed 29 October 2026.
- Credit usage, Clay University documentation, no publication date displayed. https://university.clay.com/docs/credit-usage. Accessed 29 October 2026.
- GrowthPal reporting methodology and counting rules, GrowthPal. https://growthpal.io/glossary/#methodology. Accessed 29 October 2026.
Related
- B2B list building and prospect research where the records come from before the waterfall runs.
- Cold email deliverability why unverified records are a sending problem, not just a data one.
- Cold email agency the campaign layer this build sits underneath.
- B2B lead generation agency the full program.
- Glossary and reporting methodology the written definitions behind every term above.
- Outbound sales diagnosis what to check first when a built system still underperforms.
Send us a few hundred records from the segment that matters and we will come back with the measured hit rate per provider on your own list, which is where every build should start.
A plain text version of this page is at /gtm-engineering-agency.md, and the site index for language models is at /llms.txt.