A cold campaign that works creates a second job within about a week: people answer, and now the answers need a system. Most teams handle the first ten by hand, feel fine about it, and discover at forty that the fast replies are going out in twenty minutes while the awkward ones sit for five days. This page is how we run that second job, with the numbers from our own database behind each part.
The window below is 1 July to 21 September 2026: 720 inbound messages across 26 sending profiles and 422 conversations, for our own pipeline and for client pipelines we operate. Where a number describes approvals, it covers the newer client console, live since 8 September, with 126 drafts through it.
Triage happens before the reply
The first surprise in a shared sending inbox is how much of it belongs to somebody else. Of those 720 inbound messages, 395 arrived from people we had never contacted. They are cold pitches aimed at the profile owner, platform marketing, conversations the owner started themselves years ago, and threads that a colleague runs by hand.
So the first step asks about the thread: did we send anything here? Our triage marked 499 of the 720 as needing no answer from us. Reading the recorded reason on each, at least 330 carry the same one: the thread is not ours to answer. Another 31 are closing acknowledgements, a thumbs up on a conversation that already ended, and 27 are inbound sales pitches to our own profiles.
That leaves 221 messages in the window that genuinely needed a reply. Two thirds of the volume resolved into a routing decision, and a routing decision is cheap to make and safe to repeat. The expensive part is small, and now you can see it.
One practical consequence: run the triage against the outbound record. A message that opens with a friendly greeting looks identical whether it answers our campaign or somebody else's, and the text will keep you guessing. The database knows which conversations we wrote into, and that lookup takes milliseconds.
Classes only work when the list is closed
A reply class is a label that picks the response. Ours are deliberately few: a question we can answer with a fact, a request for time, an objection about price or scope, a refusal, a routing answer that names someone else, and a stop request. Each one has a shape of response attached to it, and the shapes are what make the system reviewable.
Keeping the list short takes discipline, and we lost that discipline for a while. Our recorded reply situations number 125 over two months, and across those 125 rows there are 26 distinct class names. Alongside the plain refusal there is a closing refusal, an out of scope refusal, and a redirecting not-now. Alongside the plain question there is a pricing question and a scope-and-pricing question. Every one of those was a reasonable thing to write in the moment, and together they made the column uncountable: with 26 names on 125 rows, the classes with enough volume to learn from collapse to about four.
The newer console fixed this by hard-coding the vocabulary. Its 126 drafts carry three values: 36 refusals, 31 engaged conversations, one stop request, and 58 rows written before the field existed. That is a list you can query. It is also short enough for a person to hold in their head while reading a reply, and the human reviewer and the machine have to agree on what a thing is before either of them can be useful.
The second half of the lesson is the outcome column. Of those 125 recorded situations, 4 carry a result. Classes tell you what you saw; outcomes tell you what worked, so the loop that writes the class has to be the same loop that comes back later and writes what happened.
The clock is the system
Our rule is that nothing where the ball is on our side waits longer than 48 hours. Measured against the 221 messages that needed an answer: 199 got one, at a median of 17 minutes. 139 landed inside two hours and 190 inside 48 hours.
The median deserves a second look, because 17 minutes over three months is machine speed: a loop that watches for new inbound and drafts a response on arrival. Of the 720 inbound, 262 landed outside 07:00 to 17:00 UTC and 69 landed on a weekend, which is the ordinary consequence of writing to people in several time zones. Those arrive at hours when the person who would answer them is asleep, and a queue that opens in the morning delivers them a day later.
The honest part of the number is the tail. 22 of the 221 never received an answer at all, and 9 more crossed the 48-hour line. That is a leak of about one in ten, and it is worth naming because the median hides it completely. Whatever you build, count the conversations with a question outstanding and our name on the last message, and put that count somewhere you see daily, including your weekly outbound report. It is the only figure in reply handling that goes bad quietly.
The clock sends what the queue would hold
Whether any of this survives contact with real people comes down to one thing: what happens when a human is supposed to look at a draft.
Our console works like this: a reply arrives, the agent writes an answer, the client gets a message with the lead's words and the proposed response, and a 48-hour clock starts. The client can send it now, edit it, replace it, or hold it. When the clock runs out, the answer goes as written.
126 drafts have been through it. 66 went out and 35 were dismissed, at a median of 35 hours, which is a person reading and deciding that this one needs nothing. Of the 66 that went out, 57 left at the deadline, with a median elapsed time of exactly 48.0 hours, and 9 left earlier at a median near 5 hours. Five of those early sends came from a person pressing the button.
Two readings of that are both true. The first is that the default carries the system: with the clock removed, 57 answers out of 66 would still be sitting in a queue. The second is that people do read the drafts, because 18 of the 66 were edited before they went. Ten of those eighteen were edited and then left to expire, which is a person saying "this text is right now, send it on schedule".
The clock itself needs one correction, and it is the kind of thing only the calendar tells you. 68 of the 126 replies arrived on a Thursday or a Friday, which is when business inboxes are busiest. A flat 48-hour window puts their deadlines on Saturday and Sunday: 57 of 126 deadlines land on a weekend. The person who agreed to review answers is away from work those days, so for nearly half the queue the review step exists on paper only. Counting the clock in working hours restores it.
What happens when the gate has no default
The strongest argument for an expiring default is what a gate without one costs. Between 4 and 9 September, 52 prepared replies were frozen pending one person's decision on a question of policy. On 9 September, 51 of them were released in a single batch. 48 eventually reached the recipient, at a median of 2.2 days after the freeze, with the worst at 5.7 days. Four were cancelled, because by then the conversation had moved on and a late answer would have drawn attention to the gap it was meant to close.
Everyone in that story acted reasonably. A fair question came up, holding looked like the safe move, and the hold went in with no expiry attached. The fix is structural: every point where work waits on a person gets a safe default and a deadline, so that silence produces the conservative action on schedule.
The related failure is on the machine side. For one week in August our reply loop woke on the size of the backlog, so every unresolved item kept calling it back: 400 runs that week against 60 to 100 in the weeks either side, and 103 runs on a single day over the same handful of conversations. Once it woke on new inbound and reviewed standing debt on a slowing schedule, the same day's work took 12 runs.
What a person still owns
After all of the above, the human queue is short, and short is the point. What stays with a person: money and contract terms, any price outside the published ladder, a message that goes out signed with their own name to someone they actually know, and a decision to stop contacting a company. Everything with a knowable answer belongs to the loop, including the second message after a refusal, because a first refusal earns exactly one more short message (the full pattern is in what to do after the first reply) that takes the person's stated reason and offers one small step under it. On our own pipeline that step is a link to the self-serve tier, priced from $199 a month, so the person can weigh it in a minute and answer for the last time.
If you want one thing to apply tomorrow: open your sending inbox, count how many threads carry a question with your name on the last message, and count how old the oldest one is. That pair of numbers is your reply system, whether you designed one or not. Our published service levels describe who holds the clock at each tier, and the clock is the part that does the work. The whole loop, from signal to answered reply, is laid out on how it works.
Questions buyers ask
How fast should we answer replies to cold outreach?
Our rule is that nothing where the ball is on our side waits longer than 48 hours. Across 221 messages that needed an answer, the median response time was 17 minutes, and 190 were answered inside 48 hours. The number to watch daily is how many threads carry an open question with your name on the last message.
How much of an outbound inbox actually needs a reply?
Less than it looks. Of 720 inbound messages, 395 came from people we had never contacted, and triage marked 499 as needing no answer from us. That left 221 messages that genuinely needed a reply.
Can replies to leads be sent automatically without losing control?
Yes, with a clock. The agent drafts an answer, the client sees it with the lead's words, and a 48-hour window starts to send, edit, replace or hold it. Of 66 drafts that went out, 57 left at the deadline, and 18 of the 66 were edited first, so people do read them.
Which reply decisions should a founder keep for themselves?
Money and contract terms, any price outside the published ladder, messages signed with their own name to people they know, and a decision to stop contacting a company. Everything with a knowable answer belongs to the loop, including one short follow-up after a first refusal.