Sales Automation: Where the Line Is

The campaign structure looks fine on paper: four languages, three account tiers, two senders, two channels. The build is where it shows what that really means. Not eleven things, but forty-eight lists, sequences and copy variants, each of which has to be maintained, checked, and operated by someone after handover.

How far you automate outbound comes down to two numbers that are knowable before the build, plus one question that usually gets asked too late. This article covers all three.

What the decision actually rests on

A campaign structure is planned in dimensions and paid for in variants. Planning happens in categories that each sound harmless on their own. What gets built is their product. That gap appears in no plan and still determines the entire maintenance load of the coming months.

Four languages, three tiers and two senders are nine decisions in your head. In the build they are twenty-four combinations, and with two channels forty-eight. Each one needs its own list, its own sequence, its own copy and someone to keep it current.

Our view: if you first see the variant count while building, you have already made the decision about maintenance load without noticing. The calculation takes five minutes and belongs at the start.

This article assumes the first question is settled. Whether your market supports an outbound model at all depends on its size, and that is a separate calculation: Outbound Sales: does your market support the model? This is the question that comes after it. How we build and hand over these systems is on our pipeline generation page.

Which dimension earns its own variant

Every distinction feels like a necessary variant while you are planning. The result is a structure that looks more precise than it is, and that nobody later dares to take apart. The cost is carried by whoever has to change it six months on.

Our view: a dimension earns its own variant only when its value changes delivery, permissions or matching. If it only changes a word in the copy, it is a snippet, not a separate track.

Country is the case where this is clearest. A different country often changes only the greeting and a few phrases. As long as the same sender writes, the same permissions apply and the same record is matched, that is a text variable. It becomes its own sequence only when the country changes ownership or what you are legally allowed to do.

The last row is the uncomfortable one. Tiering almost always comes out of judgement rather than measured behaviour, which makes it fuzzy at the edges. Branching on it passes that fuzziness down to every sequence underneath.

Weekly volume, and why you calculate it backwards

The usual calculation starts at the list: this many companies, this many people, the rest follows. That is the wrong direction. What actually goes out depends on capacity per sender and on what you are trying to achieve, and both are knowable before the list exists.

Our view: the calculation runs backwards. Start with the number of positive replies you need per week, divide by the rate you can reasonably expect, and you get the number of contacts. Only from there do you get the number of senders, and whether your structure will be filled at all.

The second part is a calendar problem. Domains and mailboxes need a warm-up period before they may send at volume. Starting the setup on kickoff day spends those weeks on waiting. Those weeks are fixed, and no amount of prioritising shortens them.

Once you have run that, you usually have the answer already. If your weekly volume per variant does not fill a sequence of its own, branching is not leverage, it is administration.

Handover belongs before the build

The question of who operates the system in the month after handover almost always gets asked at the end. By then the answer is already built in. What remains is a structure that works while the agency is there and freezes afterwards.

Our view: handover is an acceptance criterion, written before the first build rather than checked after it.

In practice that means this. Someone on the team who did not build it has to be able to follow the path from table names and visible fields. Exactly one active route exists per object, not two in parallel. And while testing is under way, every writing step stays on manual, so nobody accidentally contacts real people.

The question simply changes its position in the project. At the start it costs half an hour, at the end a project.

How you know the automation actually works

A green connection looks like a passed test. All it says is that two systems talk to each other, and nothing about what happens when the same contact runs through a second time. That is exactly where duplicates and double tasks come from, and they only surface in production.

Our view: automation proves itself on the second run. The first shows that something is created. The second shows that nothing is created twice.

Send the same company and the same person through the same path again. Afterwards the same company ID has to come back, the same person ID, no second handover record, no duplicate activity, and ownership must not have moved. Only then is the system accepted.

Add the failure cases that genuinely belong to your path. A missing identifier stops before anything is created. Multiple matches stop and show the candidates for a decision. An entry on the suppression list stops before sending. You do not need more cases in the first round.

What stays automated, and the one step that does not

"Automate less" sounds like a step backwards, which is why the discussion often turns philosophical instead of specific. It concerns exactly one step in the chain. Everything before and after it stays machine work.

Our view: data, list building, enrichment, connection requests, follow-up and reporting all stay automated. Exactly one step becomes manual: the personal message, as a task per sender, assembled from approved snippets.

In our own stack that looks like this. Lemlist runs the email sequence and the mailbox warm-up, LinkedIn the connection requests and the follow-up. Underneath sits the data layer: Clay enriches company and contact data and decides which record is allowed into the system at all, and HubSpot is the system of record carrying the workflows, the ownership and the suppression lists. We are listed with both, in the Clay Solutions Partner Directory with the "Artisan" badge, the entry tier of four, and as a Diamond Partner with HubSpot.

The point is that the machine moves the human to the right place. It does not decide what the sentence says. It makes sure the sentence reaches the right person and that nobody is contacted twice.

That is the counter-test to this article's argument. What could be automated there was automated, thoroughly. What was not automated is the sentence a human writes.

Where this reverses

Everything above holds for target markets that are finite as a whole. Once the market gets large, the calculation tips the other way, and the same reasoning leads to the opposite conclusion.

Our view: where weekly volume is high, writing by hand is the bottleneck. Then branching pays for its upkeep, because it saves work instead of creating it.

The threshold cannot be given as a general number, but it can be given as a question: does your weekly volume per variant fill a sequence of its own? If it does, build it. If it does not, build a snippet and give the time to the copy.