Tags and Rules

Tags and rules are where routing quality is won in practice. Most policy instability comes from one of two things: vague tag boundaries or overcomplicated rules. If you keep both simple and intentional, routing behavior stays reliable even as volume grows.

Designing Tags That Stay Useful

A tag should represent a handling policy difference, not just a wording difference.

For example, if two message types are handled the same way by the same team with the same escalation destination, they usually do not need separate tags yet. Splitting too early creates taxonomy clutter and makes rule logic harder to maintain.

Good tags are easy for humans to understand and easy for systems to classify against. They have crisp boundaries, clear descriptions, and a clear reason to exist.

In the current routing controls, tags can also express whether a category is human-required. Use that setting only when operational policy truly requires human ownership. If everything is marked human-required, you lose the benefits of selective automation and create queue pressure.

Another practical point: foundational fallback behavior should remain protected. Treat default intent paths as guardrails, not as noise to delete.

Building Rule Logic That Operators Can Explain

Rules connect tags to destinations with priority and optional conditions. This gives you fine-grained control, but it also introduces risk if rules become too dense.

In the rule builder, you can set priority, add an optional message template override, and include conditions such as confidence ranges, message-length gates, human-required filters, and message-contains constraints.

These controls are most useful when they map to explicit policy intent. For example, a confidence range might enforce human review for uncertain high-risk content. A message-contains condition might target a known escalation keyword pattern.

What does not work well is piling on conditions “just in case.” Overconditioned rules often fail to match when they should, then teams chase downstream symptoms.

A strong rule should be understandable in one sentence. If your team cannot explain why a rule exists and when it should fire, it probably needs simplification.

Destinations and Rule Outcomes

Rule outcomes depend on destination quality as much as tag quality.

In current manual controls, destinations can route to Slack, Discord, webhook, or Zapier. Each destination type requires specific configuration, and some allow metadata inclusion options.

When rules point to outdated or loosely configured destinations, escalations can technically trigger but operationally fail. That is why destination reviews are part of routing hygiene, not a separate concern.

A practical approach is to keep destination count small and ensure each destination has a clear owner and purpose. If no team owns a destination, escalations to that destination are likely to degrade over time.

A Useful Pattern for New Teams

If you are introducing manual routing for the first time, start with one focused pattern:

• one sensitive tag,
• one destination,
• one clear rule,
• one validation scenario to test it.

Once that path behaves correctly, expand gradually.

This approach is much safer than creating a full taxonomy and rule tree in one session. Policy complexity should grow with operational need, not ahead of it.

Common Pitfalls and How to Prevent Them

The first pitfall is overlapping tags. If “billing_issue” and “refund_issue” both describe the same handling path but have unclear boundaries, classification and routing can become inconsistent.

The second pitfall is priority confusion. Teams sometimes assign priorities without a policy model, then struggle to understand why a less important route wins.

The third pitfall is noisy keyword conditions. Broad contains-any lists can trigger many false matches if not reviewed against real conversation language.

The fourth pitfall is stale rules. As products and policies evolve, old rules may remain active even when the underlying workflow changed.

The fix is regular review and intentional pruning.

Reviewing Tag and Rule Health

A strong monthly policy review usually includes:

1. Which tags are high-volume and high-value?
2. Which rules are firing rarely or unexpectedly?
3. Which escalations were clearly correct?
4. Which escalations were noisy or misrouted?
5. What can be merged, simplified, or removed?

This keeps policy understandable and keeps escalation quality high.

How Tags and Rules Connect to Validation

Never treat routing edits as complete until they are validated.

After changing tags or rules, run outcome simulations and realistic chat tests in validation. Confirm expected intent classification, route type, and escalation decision behavior.

This closes the loop between policy design and actual system outcomes.

Teams that do this consistently can evolve routing quickly without destabilizing customer experience.

Final Principle

Great routing policy is usually boring. It is clear, stable, and explainable under pressure.

If your tags and rules look elegant but nobody can predict how they behave, simplify. If they look simple and outcomes are consistent, you are doing it right.

Once your policy layer is stable, continue with Connector Overview to add runtime context safely for account-aware support.