The usual fix for an overloaded queue is a second email address, and then a third. Routing on the recipient and the sender domain instead — and the question to ask any vendor about mail that matches no rule.
The usual advice for a support team that has outgrown one queue is to create a second address. billing@ alongside support@, then onboarding@, then one per major customer. Each is trivial to create and each one is a new thing your customers have to know, get wrong, and be corrected about.
There is a better shape: keep one address, and let the system decide where each message belongs. This is what that takes, and where it goes wrong.
Route on what the message already tells you
A routing rule is a decision made from information already on the envelope, with no human reading it first. In practice there are only two facts worth routing on.
Who it was sent to. Aliases are free. support@yourcompany.com and billing@yourcompany.com can both deliver into one mailbox while remaining distinct addresses on the envelope. Your customers see separate addresses; you operate one inbox.
Who sent it. A sender's domain identifies the organisation. For anyone running support for named accounts — an MSP, an agency, a supplier with contracted clients — the sending domain is the customer, and it is the highest-signal fact on the message.
Ticku routes on exactly these two, and rules are matched in a fixed order:
- Recipient address — did the mail go to a specific alias?
- Sender domain — is it from a domain with a rule?
- The inbox default — everything else.
Recipient beats sender deliberately. If a known customer writes to billing@, they want billing, and the address they deliberately chose should outrank the domain they happen to send from. The general principle: the more explicit signal wins, and choosing an address is more explicit than having a domain.
The default is the rule that matters most
Everything above is the interesting part, and the boring part is more important: what happens to mail that matches nothing.
If the answer is "nothing", you have built a system that silently discards customer email. That is worse than having no routing, because the mail arrived, was processed, and vanished — with no bounce for the sender and no error for you.
So a Ticku inbox cannot be switched on without a default project. The field is technically nullable, but only so a half-configured inbox can be saved as a draft while you are still setting it up; enabling one without a default is refused, and only enabled inboxes are ever polled or subscribed. The result is that mail ingestion never meets a missing default, because an inbox that could drop mail never starts running in the first place.
That is worth checking in any tool you evaluate. Ask what happens to a message matching no rule. "It goes to a fallback queue" is the right answer. "It stays in the mailbox" is acceptable. Anything vaguer deserves a test message.
Rules carry settings, and inheritance runs the right way
A destination project is rarely the only thing that differs between two streams of mail. Mail from a contracted customer might warrant a higher default priority. An internal alias might not want the automatic acknowledgement that an external customer should get.
So a rule can override the inbox's settings — default priority, whether to send an acknowledgement, whether to notify on comments and status changes. What matters is how "no override" is stored.
Each override is nullable, and null means inherit from the inbox. It would have been easier to copy the inbox's current values onto each rule at creation time, and that choice quietly breaks the thing you want most: changing an inbox-level setting would then update nothing, because every rule already holds a stale copy of the old value. Storing absence rather than a mirrored default is what lets an inbox-level change propagate to every rule that has not deliberately opted out.
The same reasoning shows up in a smaller feature: rules can be disabled rather than deleted. A parked rule keeps its pattern and its overrides while doing nothing. The alternative — delete it, retype it next month — is a good description of how routing tables acquire typos.
Where this goes wrong
Three failure modes, all worth designing against.
Rules nobody can explain. A routing table that has grown for two years contains rules whose author has left and whose purpose is unrecorded. Keep the table small enough to read in one screen. If it will not fit, the shape is wrong and you probably do want a second mailbox.
Domain rules and shared email hosts. Routing on sender domain works because a domain identifies an organisation. It stops working the moment a customer emails you from a personal address, and it is actively wrong for consumer domains — a gmail.com rule routes strangers to a named customer's queue. Domain rules belong on domains your customers actually own.
Routing standing in for triage. Routing decides which queue; it cannot decide urgency, or whether two messages are the same incident, or whether something is a bug or a question. It reads an envelope. Expecting it to do triage is how teams end up disappointed with a feature that is working exactly as designed.
Is it worth it?
If you run one team with one kind of request, no — one address into one project is the whole configuration, and the routing table stays empty.
It earns its keep when the same address serves genuinely different work: support and billing, or several client accounts, or an internal helpdesk sharing an address with a customer-facing one. In those cases the alternative is not "no routing". It is asking your customers to route the mail for you, by remembering which of your addresses to use — and they will not, reliably, and the ones who get it wrong are disproportionately the ones with an urgent problem.