They take much longer after the workflow has
been dropping records in production for
eleven days.
The test environment almost never surfaces rate
limits. Test data is small. Runs are spaced out.
The limit only shows when the workflow meets
real volume.
Plan for the limit before the volume arrives.
Tests ran at two or three records. In production:
forty records every fifteen minutes at peak.
API rate limit: two hundred calls per minute.
At peak: two hundred and forty. Nobody had
thought to check the limit before scaling.
What I now build into every automation: a rate
limit check before production.
What is the limit? Volume at peak? Volume at
3× peak, because that will happen? Does the
workflow need a delay node? A queue with
a throttle? These questions take twenty minutes.
The workflow had been running for eleven days
when the errors started appearing.
Not every execution. Roughly one in seven.
The same node, the same failure, no obvious
pattern in the data.
The trigger was firing correctly. Enrichment
returning results. HubSpot write succeeding
most of the time. But on some runs, Clay API
was returning a 429, too many requests, and
the node was failing silently.
The records that failed were not being flagged.
They were being dropped.
Interested → booking workflow + suggested draft.
Rep decides whether to send.
Not-now → queued for the right interval.
Wrong-person → request for right contact.
Objection → flagged with type already labelled.
The sequence does not end when the reply arrives.
That is the moment it hands off to a person.
The quality of that handoff determines whether
the reply becomes a call or a lost contact.
Almost nothing else does.
The reply was the signal that the prospect was
ready to engage. The gap between reply and
response is where most of that readiness
quietly disappears.
This is the part automation does not fix on its
own, but can make significantly harder to lose.
What goes into every outreach system I build now:
reply classification before human handoff.
n8n reads the content and classifies intent,
interested, not now, wrong person, objection.
Each type routes differently.
Then the reply sits in an inbox for two days.
Not because nobody cares. Because there is no
defined process for what happens next. The rep
sees the notification, means to respond, and
gets pulled into something else. By the time
they return, the window has closed.
The hardest part of outreach automation is not
the outreach. It is what happens after
someone replies.
Most sequences are built toward one outcome:
a reply. The infrastructure handles the sending,
follow-ups, timing, personalisation. When the
reply arrives, the automation has done its job.
Automating the wrong part of a sales process
doesn't improve it.
It accelerates the part that was never
the bottleneck.
The right conversation isn't "how should we
automate this?" It's "walk me through the last
five times a lead came in. What happened at each
step. Where did it slow down. What required your
direct involvement that you wish hadn't."
That conversation takes forty minutes.
It surfaces the actual constraint. And the actual
constraint is almost never the thing the founder
named at the start.
Another meant CRM hygiene. Pipeline full of
unstructured data. No visibility into what was
happening. The problem was records, not outreach.
The fourth meant proposals. The bottleneck was
further downstream than any of us had expected.
Same phrase. Four completely different systems.
None of them interchangeable.