Score ticket priority with visible reasoning instead of a black-box urgent/not-urgent label

You are scoring priority for a batch of support tickets so an agent can triage the queue quickly. Every score needs a visible, checkable reason — never an unexplained label.

TICKET BATCH
22 open tickets from the last 4 hours.

PRIORITY FACTORS THAT MATTER FOR THIS BUSINESS
1) Number of users affected (most weight), 2) whether a workaround exists, 3) whether it's billing-related (real money impact), 4) account tier. Tone/wording is explicitly not a factor.

PRIORITY LEVELS AND WHAT EACH MEANS
P1 (respond within 1 hr): active outage or data loss risk. P2 (within 4 hrs): feature broken with no workaround. P3 (within 24 hrs): everything else, including questions and minor bugs with a workaround.

CUSTOMER CONTEXT AVAILABLE
3 of the 22 tickets are from Enterprise-tier accounts; one customer already escalated this same issue once last week.

HOW TO SCORE
For each ticket, weigh the factors in 1) Number of users affected (most weight), 2) whether a workaround exists, 3) whether it's billing-related (real money impact), 4) account tier. Tone/wording is explicitly not a factor. against the actual ticket content — a ticket that sounds urgent in tone (lots of exclamation points, "URGENT" in the subject) is not automatically higher priority than a calmly worded ticket describing an active outage affecting many users; score based on actual business impact described, not emotional tone of the writing. If 3 of the 22 tickets are from Enterprise-tier accounts; one customer already escalated this same issue once last week. indicates this is a high-value account or a customer already escalated once before, factor that in explicitly and say so, rather than scoring purely on the ticket text in isolation. Give a one-line reason for every score that references the specific factor that drove it — "High: affects billing for an entire team account, not just one user" not just "High priority." If two tickets in the batch would tie at the same priority level, note which should genuinely go first based on any tiebreaker in 1) Number of users affected (most weight), 2) whether a workaround exists, 3) whether it's billing-related (real money impact), 4) account tier. Tone/wording is explicitly not a factor., since a flat tie doesn't help an agent decide what to open next.

WHAT NOT TO DO
Do not inflate priority based on the customer's tone or capitalization alone — this is one of the most common mistakes and it trains customers to write in all caps to jump the queue. Do not assign the same priority level to every ticket in the batch as a way of avoiding a judgment call; if the batch genuinely has a distribution of urgency, the scores should reflect that distribution.

OUTPUT FORMAT
A table: ticket ID/excerpt, assigned priority level, one-line reason referencing the specific factor. Sorted with highest priority first.