Combined priority matrix: severity property plus account tier property

Outcome. Ticket priority is set from two signals at once, how bad the issue is and how significant the account is, instead of a single property doing double duty and getting it wrong for either a minor issue at a big account or a critical issue at a small one.

Workflow map Enrollment, branches and actions at a glance tickets-sla-025

flowchart TD
    A[Ticket created, severity known] --> B{Severity value?}
    B -->|critical| C{Account tier = enterprise?}
    C -->|yes| D[Priority = Urgent, notify escalation contact]
    C -->|no| E[Priority = High]
    B -->|major| F{Account tier = enterprise?}
    F -->|yes| G[Priority = High]
    F -->|no| H[Priority = Medium]
    B -->|minor| I[Priority = Low]

When to use it, when not to

• UseUse it once severity and account tier are both reliably captured before or at ticket creation, and a single "priority" value set from severity alone (tickets-sla-002) is not distinguishing enough between accounts.
• UseUse it when the business genuinely wants enterprise accounts to get a priority bump over an otherwise-identical issue at a smaller account, and that policy is explicit, not assumed.
• SkipDo not use it if severity alone already captures everything that matters; adding account tier only makes sense if account size is a deliberate part of your service policy.
• SkipDo not use it if severity is not reliably set at intake; a matrix built on a mostly-blank input column produces mostly-default priority values.