Labels vs folders for team email: a practical taxonomy

A customer emails about a billing error that's actually caused by a bug, and they're on your biggest plan. Which folder does that go in? If you have to pick one, you lose two-thirds of what you know about the thread.

That's the core difference between folders and labels, and it's why most teams organizing shared email end up with labels. This post explains the trade-off, then walks through building a label taxonomy for an example team from scratch.

Folders vs labels in one table#

Folders still have their place. "Inbox," "Archive" and "Spam" are naturally exclusive: a thread can't be both archived and in the inbox. But for describing what a thread is about, labels win, because real email has more than one attribute.

The catch is that labels need discipline. Without a plan, a team creates 80 labels in six months, half of them duplicates ("Billing," "billing-issue," "Payments"), and nobody trusts any of them.

The worked example: a six-person SaaS team#

Imagine a small B2B SaaS company. Six people: two founders, two support and success staff, one engineer who helps with escalations, and a part-time finance contractor. They share two mailboxes, support@ and hello@. Today they have 34 labels, created ad hoc, and nobody uses most of them.

Here's how they rebuild.

Step 1: List what people actually filter for#

Before designing anything, they ask each person: "When you look for threads, what are you trying to find?" Answers included:

• "Everything still waiting on us" (support)
• "All bug reports this month" (engineer)
• "Anything about invoices or refunds" (finance)
• "Conversations with our biggest customers" (founders)
• "Partnership and press inquiries" (founder)

This list is the real requirement. A label that doesn't help anyone find something doesn't need to exist.

Step 2: Group needs into dimensions#

The answers fall into three dimensions:

1. Status: where is this thread in its lifecycle?
2. Topic: what is it about?
3. Tier: how important is the customer?

Each dimension gets its own prefix, so labels sort together and their purpose is obvious.

Step 3: Define a small set in each dimension#

Status (at most one per thread):

• status/waiting-on-us
• status/waiting-on-customer
• status/escalated

There's no "done" label. Done threads are archived.

Topic (one or more):

• topic/bug
• topic/billing
• topic/how-to
• topic/feature-request
• topic/account-access
• topic/partnership
• topic/press

Tier (at most one):

• tier/enterprise
• tier/trial

Total: 12 labels. Down from 34.

Step 4: Write naming rules#

They agree on four rules and pin them in their team docs:

1. Lowercase, hyphens, prefix with dimension and a slash.
2. Nouns, not sentences: topic/billing, not topic/customer-has-billing-problem.
3. No person names in labels. Ownership isn't a label.
4. New labels need a one-line reason in the team channel before creation.

The fourth rule is the one that prevents sprawl. It's not bureaucracy; it's a 30-second pause.

Step 5: Set a cap#

They set a soft cap of 20 labels total. Anyone proposing a 21st has to propose one to remove. Caps feel arbitrary, but they force the conversation: "Do we really need topic/integrations, or is topic/how-to enough?"

Step 6: Migrate old labels#

For each of the 34 old labels, they decide: map to a new one, or delete. They map "Payments," "Billing" and "invoice-q" all to topic/billing. Labels with no clear purpose and fewer than a handful of threads are deleted outright. Old threads keep their history; they just stop being tagged with dead labels.

Step 7: Automate the obvious ones#

Some labels can be applied automatically. Mail from the payment provider gets topic/billing. Mail from known enterprise customer domains gets tier/enterprise. In Koltrix, labels and auto-label rules handle this kind of sender-based tagging, so people only apply the labels that need judgment, like topic/bug or status/escalated.

Status labels stay manual. They reflect decisions, and automating decisions defeats the purpose.