label:replied is not a Gmail search operator. The thing you actually want is a five-state classification.
Every existing guide on this topic teaches you to fake the label, with a Google Apps Script, a manual habit, or a third-party tool. None of them stops to ask whether a single Boolean is the right primitive for follow-up work in the first place. It isn't.
No, Gmail does not have a built-in label:replied.
The label:operator works only with labels that exist in your account. Gmail does not create a "replied" label for you. The query returns matches only if (a) you created a custom label called replied yourself, or (b) a Google Apps Script (or third-party tool with mailbox access) applied that label to messages on your behalf.
The supported is: statuses in Gmail are starred, important, unread, read, snoozed, and a handful of system flags. is:replied is not one of them. Confirmed against the official Gmail search operators reference at support.google.com/mail/answer/7190.
What people actually mean when they search this
Almost no one googling this string is asking a vocabulary question. They want one of two things: a list of the threads they have already responded to, or a list of the threads they have not responded to yet. The second is the one that drives revenue for a working consultant. It is also the one Gmail's search index cannot answer, because the index sees senders, dates, and labels, but not whether the question you asked got answered.
The four workarounds below all exist to bend Gmail into giving you a yes/no per thread. Each one is honest about what it can and cannot see. None of them is the right primitive.
The four real workarounds vs. a state classifier
The left column is what every guide teaches today. The right column is what we built into Clone instead.
| Feature | Custom Replied label (manual or Apps Script) | Clone five-state classifier |
|---|---|---|
| What it actually is | Apply a custom 'Replied' label by hand each time you hit reply, then search label:replied | A continuous classification of every open thread into one of five named states the next-action depends on |
| Maintenance cost | You must remember to label every reply forever; one missed label corrupts every future search | Zero ongoing cost; the classification is recomputed each morning from the raw thread state |
| Handles 'they replied but did not answer the question' | No. 'Replied' is a Boolean. A reply that dodged the ask still flips the bit. | Yes. The reply_dodged state fires when the planner reads the original ask, reads the reply, and detects the ask is unanswered. |
| Handles 'I owe them next vs they owe me next' | Approximated by who sent last; breaks on quoted forwards, BCC chains, and aliased replies | Direction is computed from the thread body, the contract value, and your CRM stage; not from the From field |
| Survives a stack change | Apps Script is locked to Gmail; manual labels die when you migrate aliases or domains | Reads the inbox visually through the Computer Agent layer; works the same on a personal Gmail and a Workspace alias |
| What it produces | A search result list. The work of figuring out who needs what is still on you. | Drafts in your Drafts folder, one per qualified thread, scoped to the specific state the thread is in |
What Gmail actually exposes (and what it doesn't)
For completeness, here is the operator reality, in case you want to keep building label-based workarounds. We are not against them; they just are not the answer to the question that sent you here.
| Feature | What the operator does | Reality |
|---|---|---|
| label:<name> | Matches messages tagged with a Gmail label of that name. Returns zero unless you (or a filter, or an Apps Script) actually applied a label called replied. | Same. Clone does not invent operators; it does not require any label, custom or built-in, to do its work. |
| is:starred / is:important / is:unread | These are the only is: statuses Gmail's official operator reference lists. is:replied is not in the list. | Confirmed against the Gmail Help reference on 2026-05-03. |
| in:sent + subject filtering | in:sent subject:-(Re: OR Fw: OR Fwd:) approximates 'messages I started.' It does not tell you which were responded to. | An approximation of the wrong thing. The right primitive is per-thread state, not a sent-mail filter. |
| has:userlabels | Returns messages with any user-defined label. Useless on its own for the replied question; works only if your filter strategy is already disciplined. | Discipline is the failure mode. A ritual that recomputes state daily does not depend on you labelling anything. |
The category error: Boolean vs. classification
A label is a Boolean. A thread either has it or it doesn't. That works fine for tagging newsletters or marking taxes. It breaks for follow-up work because two real-world cases collapse into the same bit:
- Reply dodged. Client wrote back. Their reply did not answer the question you asked.
label:repliedcalls this thread resolved. It is not. - Wrong direction. They sent the last message, which means you owe nothing.
-label:repliedwould surface this thread as needing your action. It does not.
What you need is a per-thread label that names which kind of pending state the thread is in, not whetherit's pending. That is what the inbox-triage ritual computes.
Why no Gmail operator gives you the list you want
What you typed: label:replied
Returns zero results, unless a label literally named "replied" exists in your account and you (or a script) applied it.
The five states that replace label:replied
Every open thread is in one of these states or it is skipped. The names are not metaphors. They are how the classifier writes its output to the morning digest. You can read or edit the rules in memory/rituals/inbox-triage.md, a plain markdown file inside your Clone install.
promise_pending
You said you would send something by a date. The date is within 24 hours or has passed. The thread doesn't need a reminder; it needs the actual artifact.
proposal_awaiting
You sent a proposal. They opened it. They haven't replied. The follow-up references the specific option you recommended, not a generic bump.
reply_dodged
They replied, but the reply did not answer the question. label:replied would call this resolved. It isn't. The follow-up quotes the original ask.
countersign_waiting
You signed an SOW or MSA. It has been sitting in their queue for more than three business days. The follow-up is a two-line nudge with the doc link inline.
deliverable_shipped_no_ack
You sent the deliverable. No reply. Not even a thanks. The follow-up asks one concrete question about the deliverable so the silence has somewhere to land.
How a single thread becomes a state, not a label
The classifier does not write to Gmail. It reads from Gmail, consults your ritual file, picks a state, and writes a draft into Gmail's native Drafts folder. Your label structure stays exactly as you have it.
One thread, one morning
The label question lives in Gmail. The state question lives across the rest of your stack.
What the classifier reads to pick a state
Gmail
primary inbox, sent folder, drafts; aliases and 'send mail as' supported
Google Workspace
secondary work alias and shared inboxes are read alongside the personal address
HubSpot
deal stage and contract value gate which threads route to review_first
Pipedrive
alternate CRM source; the inbox-triage ritual is CRM-agnostic
Calendly
your calendar-busy blocks suppress drafts during back-to-back call days
QuickBooks
invoicing context for promise_pending threads tied to a milestone payment
Slack
the morning digest lands here, not in another inbox
Zoom
transcripts feed the original-ask context for reply_dodged classification
If you still want the literal label
Three honest paths to making label:replied return matches in your account today, ranked by maintenance cost:
- Manual. Create a label called
repliedin Gmail. Apply it to every reply you send. The search will start returning matches the moment you label your first one. The maintenance tax is forever, and the data is wrong from the day you forget. - Apps Script. Write a time-driven trigger that walks
in:sent newer_than:1deach hour and applies the label to threads whose latest message is from you. Edge cases (aliases, BCCs, calendar invites) need additional handling. Plan to maintain it. - Third-party plugin.Tools like GMass and Mixmax expose their own "needs reply" label by tracking outbound emails through their own pixel. Useful if you already pay for one of them. They do not classify; they flag.
None of these answers the question your inbox actually has every morning, which is which threads do I owe a move on, and what kind of move. That is the gap Clone fills. The five-state classifier runs whether or not you keep your manual label habit.
Walk through inbox-triage.md on your real inbox
Thirty-minute call. Screen share. We open memory/rituals/inbox-triage.md, point each state's pull rule at three of your live threads, and you watch the classifier write drafts into your Gmail Drafts folder before we hang up.
Frequently asked questions
Is label:replied a real Gmail search operator?
Only in the literal sense that label: is a real operator and replied is a string you can search for. There is no built-in 'replied' label in Gmail, so label:replied returns zero results unless you have created a custom label called replied in your account and applied it (or a Google Apps Script applied it) to specific messages. The official Gmail Help reference at support.google.com/mail/answer/7190 lists the supported is: statuses (starred, important, unread, read, snoozed, encrypted, and a few more); replied is not in the list.
How do most people make label:replied work?
Three patterns. One: a Google Apps Script that fires on a time-based trigger, walks recent threads, and applies a custom Replied label to threads where the most recent message in your sent folder appears. Two: a manual habit where you click the Labels button on every reply you send (most people abandon this in week two). Three: a third-party tool that watches your inbox via OAuth and applies its own label. All three encode a Boolean (replied / not replied) per thread. None encode why the next message is owed or by whom.
What is wrong with a Boolean?
Two problems. First, replied flips to true when the client sends back 'thanks, this is helpful' even if the actual question you asked was ignored. Second, replied does not distinguish a thread where you owe the next move from one where they do. For a working consultant, those are the only two pieces of information that matter, and a single label collapses them. Five named states (promise_pending, proposal_awaiting, reply_dodged, countersign_waiting, deliverable_shipped_no_ack) preserve both.
Where do those five states live in Clone?
In a plain-text file at memory/rituals/inbox-triage.md inside your Clone install. You can open it in any text editor. Each state is a stanza with a pull rule (which threads qualify), a voice rule (which prior message style to mimic), and an auto_send flag (whether the draft is sent automatically or held for review). The triage ritual reads this file each morning, classifies every qualifying thread, and writes drafts into your Gmail Drafts folder.
Does Clone need to apply a label to my Gmail?
No. Clone does not write labels into Gmail. Threads are classified in memory each morning and the output is written into your existing Gmail Drafts folder. Your Gmail label structure is yours and Clone leaves it alone. You can still maintain a manual Replied label or an Apps Script if you want one for your own searching; the classification runs in parallel.
Will the classifier mark a thread as replied when it shouldn't?
The classifier never writes 'replied.' It writes one of the five state names, or it skips the thread. The skip cases are explicit: skip if the client replied in the last 24 hours, skip on out-of-office auto-replies, skip on do-not-contact contacts, skip during your own calendar-busy blocks. On top of that, contracts above the contract_value_threshold force review_first regardless of state, so high-value engagements always get your eyes before a draft is sent.
What about quoted forwards and aliased replies that confuse Gmail's threading?
This is the case where a label-based approach loses worst. If a client replies from a different alias, Gmail starts a new thread, your label:replied search misses it, and your Apps Script can't tell it is the same conversation. Clone classifies on body content (the original ask, the deliverable, the contract value) not on the From field, so an aliased reply still maps to the same state in the same engagement.
Can I see the operator-style answer at the top of this page in one line?
Gmail does not have a built-in label:replied operator. label: works only with labels that exist in your account, and 'replied' is not one Gmail creates for you. Verified against the official Gmail Help reference (support.google.com/mail/answer/7190) on 2026-05-03.
Adjacent guides on follow-up work
Email Follow-Up Automation That Starts With A Read, Not A Send
The morning triage ritual that drafts five states' worth of follow-ups before you open Gmail.
Automate Consulting Follow-Ups
How to turn the post-call hour into one Slack approval instead of an afternoon of switching tabs.
Consulting Follow-Up Automation
The single follow-up after a single call: how the content is composed in your voice from the transcript.