What should we actually automate in go-to-market?
Automate the work that is continuous, high-volume and judgement-free: observing, enriching, classifying, detecting change, drafting and monitoring. Keep human the work that is relational, ambiguous or consequential: judgement calls, negotiation, and any decision the system cannot explain. The dividing line is not how difficult the task is — it is whether doing it well requires a model of a person.
The question is usually asked backwards
"What should we automate?" is normally asked as a tooling question — which parts of the workflow can a model do now. That framing produces a list of tasks ranked by how impressive the demo was, which is why so many teams end up with an AI that writes emails and no improvement in pipeline.
The useful version is an architecture question: which work does this system do continuously, and which work does it do once, carefully? Machines are extraordinary at the first and unreliable at the second. Humans are the reverse.
The dividing line
The line is not task difficulty. Plenty of hard work should be automated and plenty of easy work should not. The line is whether doing the work well requires a model of a specific person — their situation, their incentives, what they are not saying.
Automate: continuous, high-volume, judgement-free
- Observing — watching accounts for change, permanently, at a volume no team can staff.
- Enriching — resolving what is true about a company from external evidence.
- Classifying — sorting accounts, roles, behaviours and events into categories.
- Detecting — comparing current state against prior state and flagging difference.
- Drafting — producing a first version of something a human will send or approve.
- Monitoring — noticing when a metric, a deal or an account departs from its pattern.
Keep human: relational, ambiguous, consequential
- Judgement — calls that depend on context the system has no way to hold.
- Relationships — trust is not a workflow and does not survive being one.
- Negotiation — reading the other side, and being read.
- Ambiguity — situations where the right move is genuinely unclear.
- Strategy — deciding what the system should be trying to do at all.
Most companies have this ratio inverted. They under-automate observation, because it is invisible and nobody demos it, and over-automate action, because it is legible and looks like progress. The result is a system that sees very little and does a great deal about it.
The prerequisite nobody checks
Before automating any action, the architecture underneath has to support it. Three questions, and if any of them produces a debate rather than an answer, the action layer is not the thing to automate next:
- Can the system say what changed about this account, and when?
- Is there a stated rule for what should follow that change — or is the tool's default behaviour now the policy by accident?
- Will you be able to tell afterwards whether the action caused anything?
Automating an action without the third is the expensive one. You get volume, no attribution, and no way to distinguish a working system from a busy one. That is the mechanism behind why AI SDRs fail.
A sequence that works
Roughly in this order, because each step makes the next one safe:
- Observation first. Automate knowing things. It is low-risk, compounding, and every later layer depends on it.
- Detection second. Automate noticing change. Still no outbound consequence if it is wrong.
- Decision third, explicitly. Write the rules down. A rule you can read is a rule you can correct.
- Action last, and narrowly. Start where a wrong action is cheap. Widen as feedback confirms the rules.
- Feedback throughout. If you build it last you will never build it.
The test to apply to any proposal
Two questions. If a machine makes this call and gets it wrong, what does it cost — and could you reconstruct afterwards why it decided that? A decision that is cheap to get wrong and possible to explain is a good candidate. A decision that is expensive to get wrong and impossible to explain is not automation; it is the removal of a decision from the organisation.
Producing that map — which work belongs to machines, which to humans, and in what order to move — is the fifth layer of the GTM Architecture Audit.
Should we automate outbound entirely?
Not as a first move, and not on the current architecture in most companies. Outbound is an action layer, and automating actions is only safe once the system can say which account changed, what changed, and whether the last action caused anything. Automating a process that cannot answer those three questions increases the volume of a thing that was not working.
Where do teams most often automate the wrong thing?
Message generation. It is the most visible task, the easiest to demo, and almost never the constraint. The constraint is usually that nobody can say which accounts deserved contact this week. Automating drafting on top of that produces more output of the same quality, faster, which is not an improvement.
Does this mean we should automate less than we planned?
Usually it means automating different things, not fewer. Most companies under-automate observation — enrichment, monitoring, classification, change detection — because it is invisible work that no one demos, and over-automate action because it is legible. Correcting that ratio typically increases total automation while reducing the number of automated decisions.
How do we decide case by case?
Ask whether the work requires a model of a specific person. Classifying a job posting does not. Judging whether a champion has gone quiet because they are busy or because they are leaving does. Then ask whether you could explain the decision afterwards. If a machine makes a call you could not reconstruct, you have not automated a task — you have removed a decision from the organisation.