Teaching Claude to Read Cold-Email Replies Like a Sales Rep, Not a Keyword Filter

Most cold-email systems handle replies with a keyword filter: scan for "unsubscribe" or "no thanks," bucket everything else as a lead. That's not reading a reply. That's pattern-matching on a handful of phrases and hoping the rest sorts itself out.

The setup

Every campaign eventually gets replies that don't fit a template. "I'm good thanks" is a decline, but it doesn't contain "no" or "stop." An out-of-office autoresponder isn't interest, but it also isn't explicitly declining anything. And every so often someone replies with something that reads as ambiguous even to a human.

The build

Instead of a keyword filter, the reply gets sent to Claude with a straight three-way classification: INTERESTED, OPT_OUT, or AUTO. Based on the label, the system acts immediately — no human has to triage the inbox first:

That's the whole mechanism. The actual engineering work is in what counts as evidence for each label, not the branching logic.

Where it actually got tested

A reply like "I'm good thanks" correctly classified as a decline — no explicit "no," but the tone reads as one to any human, and it should read as one to the classifier too. An out-of-office reply got correctly ignored rather than treated as either interest or rejection. Those are the easy cases a keyword filter would have gotten right too, honestly.

The harder case: a reply that just echoed a phrase back from our own follow-up email — someone bumping a thread we'd already bumped, in a way that could've read as mild sarcasm or a real request for a response. The classifier called it INTERESTED. We're genuinely not sure that was right, and we'd rather say so than quietly count it as a win. That's the actual edge of what a classifier like this can do reliably.

The reusable idea

Any system reading unstructured human text for a business decision needs three things: a label set that matches what you'll actually do with the answer, a default path for the ambiguous middle instead of forcing a binary, and — the part people skip — a habit of checking the cases where it might have gotten it wrong, not just the ones where it obviously got it right.