Settingsintermediate

Rule resolution reference

When multiple opening-hours rules might apply to the same conversation, how Atender picks one. Plus the matching matrix (team + channel beats team beats channel) and what happens when no rule matches.

4 min read

Rule resolution reference

When you have multiple opening-hours rules, the obvious question is: which one wins for a given conversation? This reference covers the resolution logic.

The matching matrix

Opening hours can be assigned in four modes:

  • Inherit/default — Use the tenant default opening hours
  • Always open — Treat the conversation as inside opening hours
  • Always closed — Treat the conversation as outside opening hours
  • Custom rule — Use the matching matrix below to pick the most specific active rule

Explicit Always open and Always closed assignments win before normal rule matching. If a team or channel is pinned to one of those modes, Atender uses that result directly and does not continue through the specificity matrix.

Inherit/default means “use the tenant default.” It does not create a more specific override by itself.

For custom rules, a rule “matches” a conversation when its scoping covers the conversation’s team and channel. Three levels of specificity, scored:

  • Team + Channel — 3 — The most specific match — beats everything else
  • Team only (any channel) — 2 — Used when no team+channel match exists
  • Channel only (any team) — 1 — Fallback when only the channel matches

This is the same scoring model as SLA assignments — for the same reason: it lets you set broad defaults and override narrowly without rule duplication.

Worked example

Three rules:

  • Default Email — (any) — Email
  • Premium Team — Premium — (any)
  • Premium Email — Premium — Email

A conversation routes to the Premium team on the Email channel. Resolution:

  1. Premium Email matches both team and channel → score 3 → wins.
  2. The other two rules don’t run; they’d have lost on score anyway.

Same conversation but on Web Chat instead:

  1. Premium Email doesn’t match (channel is Email, not Web Chat) → skipped.
  2. Premium Team matches the team → score 2 → wins.
  3. Default Email doesn’t match (channel doesn’t include Web Chat) → skipped.

A General-team conversation on Email:

  1. Premium Email doesn’t match (team is General, not Premium) → skipped.
  2. Premium Team doesn’t match → skipped.
  3. Default Email matches the channel → score 1 → wins.

Assignment mode example

Your tenant default opening hours are Monday–Friday, 09:00–17:00.

You then pin the Email channel to Always open.

Resolution:

  1. A conversation on Email uses Always open immediately.
  2. The normal matching matrix is skipped for that conversation.
  3. The conversation is treated as inside opening hours even on Saturday or outside 09:00–17:00.

A Web Chat conversation with no explicit override uses Inherit/default, so it follows the tenant default: Monday–Friday, 09:00–17:00.

When no rule matches

If a conversation’s team and channel combination doesn’t match any active rule, downstream features that read opening hours fall back to default behavior:

  • SLA timers — count continuously (no pausing — same as if Ignore office hours were on)
  • Automation rules with schedule restrictions — schedule restrictions evaluated as “always inside hours” (the rule fires regardless)
  • IVR Is Open node — defaults to closed (caller routes to the after-hours branch)
  • Web chat widget — shows as available

The defaults vary by feature. The safest move is to ensure every team-and-channel combination you actually use is covered by at least one rule.

When two rules tie on score

It’s possible — though rare — for two rules to tie on specificity. Two channel-only rules both targeting Email, or two team-only rules both targeting the same team. When this happens, the resolver picks one but the choice isn’t well-defined.

Fix it by either:

  • Making the rules disjoint (one covers Email + Premium team only, the other covers Email + General team only), or
  • Merging them into a single rule, or
  • Disabling one (the active toggle) and seeing if the remaining behavior is correct

Active vs inactive

A rule with the Active toggle off is treated as if it doesn’t exist for resolution purposes. Useful for:

  • Temporarily testing a different schedule (toggle the new one on, the old one off, compare)
  • Holiday schedules that only apply for a few weeks of the year (toggle on at the start, off afterward)
  • Rules under construction that aren’t ready to apply

Inactive rules don’t count in tie-breaking either — they’re invisible to the resolver.

Audit trail

When a feature reads opening hours for a conversation, it records which rule applied. SLA badges and IVR flows expose this in their respective dashboards. If a rule fires (or doesn’t fire) when you didn’t expect it, this audit trail tells you why.

See also

Tags

Reference