KoltrixAuto-label rules that stay maintainable after a year
Why email rule sets rot and a checklist to prevent it: one purpose per rule, clear names, a documented why, testing on real mail, and quarterly pruning.
On this page(4 sections)
The first ten auto-label rules feel like magic. The fiftieth rule is the one nobody remembers writing, which conflicts with rule twelve, which was written by someone who left the company last spring.
Rule sets rot slowly and quietly. Nobody notices until a customer email ends up in the wrong place and three people spend twenty minutes figuring out why. This post explains how rot happens and gives you a checklist for writing rules that are still understandable a year from now.
How rule sets rot
Rot usually comes from a few predictable sources.
Overlapping conditions. Rule A labels anything from @vendor.example as Vendors. Rule B labels anything mentioning "invoice" as Finance. A vendor invoice now gets both, which might be fine, or might trigger two different workflows. Nobody designed the overlap; it accumulated.
Senders change. A tool switches its notification address from [email protected] to [email protected]. The rule silently stops matching, and notifications flood the main view. Or worse, a domain you labeled as "Customer: Acme" starts sending marketing from the same address.
Nobody owns them. Rules are created in a moment of irritation ("I'm sick of these notifications") and never revisited. The person who wrote them knows why; nobody else does.
Rules that encode temporary situations. "Label everything from the conference organizer as Urgent" made sense in March. In November it's still running.
Patch on patch. Instead of fixing a broken rule, someone adds another rule to correct its output. After a few rounds, the behavior depends on evaluation order nobody understands.
The checklist
Use this when writing a new rule and when reviewing old ones.
1. One purpose per rule
- The rule does one thing, for one reason.
"Label payment provider emails as Billing" is one purpose. "Label payment provider emails as Billing, mark them read, and also catch anything with 'receipt' in the subject" is three rules wearing a trench coat. Split them. Small rules are easier to debug and easier to delete.
2. Name it so a stranger understands
- The rule's name says what it matches and what it does.
Good names follow a pattern like [source] → [action]:
payments-provider → label:billing
ci-notifications → label:updates, skip main view
enterprise-domains → label:tier/enterprise
Bad names: rule 7, fix, new one, Ana test. If your tool doesn't support names, keep a short shared doc that lists each rule with a name and description.
3. Write down why
- There's a one-line reason recorded somewhere the team can see.
The "why" is what lets someone safely delete or change a rule later. Example:
| Rule | Why | Added by | Date |
|---|---|---|---|
| payments-provider → billing | Finance reviews all payment mail weekly | Dee | Jan |
| ci-notifications → updates | Engineers get these in chat already | Ben | Feb |
| conference-org → urgent | Speaker deadlines during event prep | Ana | Mar (temporary) |
That last row flags itself as temporary. Next review, it goes.
4. Match narrowly
- The condition is as specific as it can be while still doing its job.
Prefer exact sender addresses over whole domains when the domain also sends other kinds of mail. Prefer sender conditions over subject keywords, because subjects vary and keywords collide ("invoice" appears in customer complaints about invoices, too). Broad rules catch more than you intended, and over-matching is harder to notice than under-matching.
5. Test against real recent mail
- Before enabling, you checked what the rule would have matched in the last week or two.
Search your mailbox with the same conditions. Look at every match, or a good sample if there are many. You're checking for false positives: a customer who happens to email from a vendor domain, a person whose message contains your keyword. Five minutes of testing saves hours of confusion.
6. Think about order and overlap
- You know what happens if this rule and another both match.
If your tool applies rules in order, or lets one rule stop others from running, write that down. If all matching rules apply, check whether the combined labels make sense. A thread labeled both tier/enterprise and updates might be a real enterprise customer whose message was mistaken for a notification.
A practical principle: rules that protect important mail (always keep in main view) should win over rules that remove noise (skip the main view). A missed notification is cheap; a hidden customer is not.
7. Prefer rules for senders, AI for meaning
- The rule is based on who sent it, not on interpreting what it says.
Rules are excellent at "this exact sender always means this." They're poor at "this email is about pricing." If your inbox has AI classification, let it handle intent and keep rules for deterministic cases. In Koltrix, for example, AI sorting handles the broad categories while labels and auto-label rules cover the senders you know for certain.
8. Prune quarterly
- Rules are reviewed on a schedule, with an owner.
Once a quarter, go through the list:
- Delete rules whose sender hasn't emailed in months.
- Delete rules marked temporary whose reason has passed.
- Merge rules that do the same thing.
- Fix or remove rules that people work around manually.
- Confirm each remaining rule still has a known reason.
Put the review on someone's calendar. Shared ownership in practice means no ownership.
A healthy rule set at a glance
After a year, a well-maintained rule set for a small team tends to look like this:
- A modest number of rules, each with a clear name
- A documented reason for every rule
- Mostly sender-based conditions
- A couple of protective rules that keep critical senders visible
- No rules nobody can explain
If you can hand the list to a new teammate and they understand it in ten minutes, it's maintainable.
Key takeaways
- Rule sets rot through overlap, sender changes, missing ownership and patch-on-patch fixes.
- One purpose per rule, a descriptive name and a recorded reason prevent most problems.
- Match narrowly, test on recent mail, and think about overlap before enabling.
- Use rules for known senders and leave fuzzy intent to classification.
- Prune quarterly, with a named owner.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
