In emergency rooms, the first thing that happens to a patient is triage. A nurse decides who is bleeding out, who is uncomfortable, who can wait. The doctor never sees the queue. The doctor sees the next patient, in order, with a tag explaining why they are next.
Your inbox does not have a triage layer. It is the queue. You are the doctor. You see all 200 patients at once. They are ranked by who walked in most recently.
What triage is, in software
Triage is a layer that reads incoming work and orders it by what matters, not by what arrived. It is not a folder. It is not a filter. It is not a summary. It is an ordered, opinionated list of the next decisions you have to make.
In software, a triage layer answers three questions on every thread:
- Does the recipient need to do anything? (Reply, decide, attend.)
- By when? (Today, this week, optional.)
- Why is this on the list? (VIP sender, deadline, follow-up, frustrated tone.)
If your tool does not answer those three before you open the message, it is not a triage layer. It is just an inbox.
Why nobody has built it well
Three reasons.
One, triage requires opinion. The tool has to be willing to say “your boss is more important than your newsletter.” Most email clients have refused to be that opinionated, because they want to be neutral platforms.
Two, triage requires history. Knowing that this is the third follow-up from a frustrated client requires understanding the past, not just the current message. Most clients lack the data model.
Three, triage is hard to demo. A triage layer working well looks like a quiet inbox. A summary feature working well looks like magic. Magic ships. Quiet does not.
The best triage system you ever use will be the one you stop noticing.
What we mean when we say STAMP is a triage layer
STAMP classifies every incoming thread along several axes:
- Reply needed vs informational vs auto-generated.
- VIP sender vs known contact vs cold outreach.
- Urgent (deadline today, server down, payment overdue) vs ordinary vs whenever.
- Frustrated (sentiment shift in tone) vs neutral.
- Follow-up count (zero, first, second, third).
Those tags compose into a priority. The seven threads with the highest composite score get the headline. Everything else is one keystroke away.
We do this on-device. The classification model is small enough to run locally, fast enough that you do not see latency. We covered the technical side in on-device email classification, explained.
Why this is not just “Gmail Priority Inbox”
Gmail's Priority Inbox tried something similar in 2010. It used a single signal (do you read messages from this sender) and made a binary decision (important or not). It was a good idea, weakly executed.
STAMP uses many signals, makes many decisions, and exposes the why. The why is the part that matters. “Important” without a reason is just a different kind of noise.
Triage layer design notes (for the curious)
If you are building something in this space, three notes from our experience.
Order matters more than scoring. Users do not want to know that an email scored 87/100. They want to know it is the third thing on the list today. Surface the rank, hide the math.
Be opinionated about the tag set. We started with 23 tags. We shipped with 8. The 15 we cut were ones the user was supposed to choose. Nobody chose. Pick a small, complete set and apply it automatically.
Make the override easy. Users will sometimes disagree with your triage. The fastest correction (one keystroke to bump a thread up or down) earns trust. The slowest (a settings page) loses it.
What this looks like for users
Two scenes from our early access.
A founder opens her laptop. Top of the inbox: a thread with her largest customer, tagged “Frustrated, 3rd follow-up.” She had not noticed she was being asked the same question three times. Triage saved a relationship.
A freelancer opens his laptop. Top of the inbox: a 4-day-old thread from a CFO with the word “Approved” in the body. Tagged “Reply needed.” He had skimmed the subject line and assumed it was an FYI. Triage saved $14,000 of work.
Both stories are from the first two weeks of a single quarter. We have a folder of them.
What is hard about this
The honest part: triage is never perfect. Edge cases exist. A thread tagged Reply needed sometimes does not need a reply. A thread tagged FYI sometimes really needed your eyes.
We aim for “right 95 percent of the time, easy to correct the rest.” That is the bar. Anyone who tells you they have nailed 100 percent has not shipped to enough users.
Where to go from here
If this resonates, the practical follow-up is the 7-email rule. The product version is STAMP for founders or STAMP for operators.
If you want to argue with us about the design, the email is at the bottom. We read everything.
The triage layer your inbox was missing. hello@stamp.email