The 'Interested' label in your inbox is lying to you

Every inbox tool that sorts replies into buckets does one of two things underneath. It matches patterns, looking for words and shapes that usually appear in a positive reply. Or it asks a language model to read the message and pick a category. Most systems that do this well use both, in that order, because the two fail in different places.

Rules are fast, cheap and completely predictable. They are also literal. A rule that treats "what does it cost" as interest will fire on "what does it cost, because we are not buying anything this year". A rule that keys on a question mark will fire on "are you going to keep emailing me?" These are not exotic edge cases. They are how people write when they decline politely.

A language model handles that phrasing better, because it reads the sentence rather than scanning it. It brings a different failure. It infers from tone, so a warmly worded no reads more like a yes than a curt but genuine "send me details" does. It is also non-deterministic in a way rules are not. The same message can land in a different bucket on a different day.

Neither failure shows up in the interface. What arrives in front of you is one word, in a coloured chip, next to a message you have not read.

What makes a label misleading is not that classifiers are inaccurate. It is that the output throws away the part that would tell you whether to trust it. Inside the system there is a difference between a reply that matched three strong signals and one that scraped past a threshold on a single weak one. By the time it reaches the list view, both are the word "Interested", rendered identically.

This matters because of what people do next. A label that looks certain invites the reader to skip the step it was meant to speed up. Instead of reading the reply and deciding, they read the label and decide. Now a rule written months ago is making qualification calls on live conversations. The label was supposed to be an assistant. It has quietly become the decision-maker.

SalesCrew keeps the label narrow on purpose. Classification runs rules first, with a language model as a fallback that returns a label only, not an action. Under the default agent policy, classifying a reply and pausing a cadence in response both run automatically, because both are cheap to undo. A wrongly paused cadence can be resumed. A wrong label can be corrected. Everything a wrong label could turn into a real mistake sits behind review. The Inbox agent drafts a reply, but the draft waits in the approval queue, where the person approving sees the actual thread beside the draft, not a summary of it.

That queue design is the practical answer to the confidence problem. The review item shows the artefact and the evidence that produced it: the thread itself, the score, the knowledge base sources the draft drew on. A reviewer does not have to trust the label. The material the label came from is right there.

Use labels to decide reading order, not to decide who gets read. If two hundred replies arrive overnight, sorting the twelve marked positive to the top is a real gain. Deleting the other one hundred and eighty-eight unread turns the gain into a loss. The failure mode of these classifiers is precisely the quiet, mildly worded genuine interest that reads as neutral.

Sample the buckets you are not reading. Once a week, open a handful of replies the system marked as not interested and see whether you agree. This is the only way to find out what your rules are doing, and it takes minutes. If a bucket keeps containing things that should not be there, the rule needs changing, and you now have the examples to change it with.

Keep a human between the label and any action that reaches a person. A label can safely pause a cadence, sort a list, or add a tag. It should not, on its own, send a reply, move a deal to a new stage, or create one. In SalesCrew those all sit in review by default. The reason is the reason this post exists: the label looks like a fact and is a guess, and the cost of a wrong guess depends entirely on what you let it trigger.

When you reject a draft in the review queue, write the reason. The rejection reason feeds the next run. That is how a review queue turns from a checkpoint into a feedback loop. A classifier nobody corrects stays exactly as wrong as it was on the day it was configured.