Routing without regex.

Pattern-matching rules decay for a predictable reason: they encode how customers phrase things, and customers keep finding new phrasings. The regex that catches "invoice" misses "you charged me twice." So you add a rule. Then a rule for the rule's false positives. Each patch is rational; the pile is not.

Worse, the rules become load-bearing and illegible at the same time. When routing misfires, debugging means replaying a customer's sentence through forty conditions in priority order. That's a job for a compiler, and your support lead is not a compiler.

There's a staffing cost hiding in there as well. A rule pile is private knowledge — the person who wrote it can maintain it, and everyone else routes around it. When that person leaves, the rules keep firing, unexamined, for years. We've watched a team keep an entire mail alias alive because nobody was sure which automation depended on it.

Routing should be a vocabulary, not a program.

InboxBarn's routing layer is deliberately blunt: every conversation carries exactly one category — general, VIP, billing, or sales. That's the whole taxonomy. Not forty tags, not nested queues. Four words that map to the four genuinely different ways a small team responds: the default lane, the drop-everything lane, the money lane, and the future-money lane.

The categories do their work on the destination side. Your team channels subscribe to categories the way you'd say it out loud: billing conversations go to the finance channel; VIP goes to the founders' channel; everything reaches the dashboard. When someone asks "why did this land here?", the answer is one sentence, every time.

Sources get a default category too, which covers most routing before any per-thread decision happens — your sales@ address can default to sales, your site's chat widget to general. Recategorizing a conversation later is one click, and the destinations follow.

One category per conversation is the other deliberate constraint, and it's the one people resist. Tags feel safer — why not billing and VIP both? Because routing needs a single answer to a single question: who should see this next? A conversation that's both billing and VIP is, for routing purposes, VIP; the billing detail lives in the thread, where your teammate will read it anyway. Multiple tags reintroduce priority ordering, and priority ordering is how the regex pile started.

The other half of routing isn't "which queue?" — it's "which person?" That's assignment, and it deserves to be a first-class verb rather than another pattern rule. Assign a conversation to a teammate and it's theirs until it's resolved or handed off; the inbox's "Assigned to you" filter becomes each person's actual worklist.

If your team works out of Discord, assignment even routes physically: a /assign command hands the conversation over, and each assignee can have their own category so their conversations gather in their corner of the server. Assignee wins; category routes otherwise. Two rules, both speakable.

Notice what this replaces: the auto-assignment rules, the round-robin engines, the load-balancing settings page. For a team of five — or twenty-five — a human glance at the queue during the Monday triage assigns the week's work faster than any rule you'd trust, and the act of assigning is itself a small review of what's actually in the queue.

Here's the entire routing config of a five-person team we'd consider well-run, expressed in the only notation it needs:

• Support email and the web chat widget default to general.
• sales@ defaults to sales; anything from a named enterprise contact gets flipped to VIP by hand.
• The #billing Slack channel subscribes to billing. The #leads channel subscribes to sales. The founders' channel subscribes to VIP.
• The dashboard receives everything — it always does — so nothing can route into a void.

Follow one message through it: a customer emails about a doubled invoice. The email source files it under general; whoever sees it first flips it to billing; the finance channel lights up; someone assigns it to Priya because she set this customer up in March. Four words of vocabulary, one click of correction, zero rules consulted.

The setup also fails gracefully. When a regex pile misroutes, the thread lands somewhere wrong and confident — a billing dispute sitting in #general until someone complains. When a category is wrong here, anyone who notices flips it, the destinations re-sync, and the correction took less time than reading this sentence. Systems that are cheap to correct don't need to be perfect, which is exactly what frees them to be simple.

Notice what's absent: priority weights, rule ordering, escape hatches. When a conversation lands somewhere surprising, you read four sentences and find the culprit. That property — auditable by reading — is worth more than any cleverness a pattern engine can buy you, and it's the same philosophy behind running support as one thread: fewer moving parts, each one visible.

If your current rule tab has become an archaeology site, the fix isn't better regex. It's a smaller vocabulary. Start with four words and see how far they go — in our experience, much further than forty rules ever did.