Use this matrix to give routine, time-sensitive, restricted, and urgent customer requests a consistent first route. It helps a teammate tag the request, gather the right facts, and send it to the right owner. It does not set an SLA, approve a refund, change a price or policy, decide an access or security issue, or authorize a customer commitment.
The priority bands below are fictional working examples, not response guarantees or universal service levels. Replace labels, owners, coverage rules, and escalation triggers with the business's approved process before live use.
Use the more restrictive route when a request fits more than one band, the facts are incomplete, or the worker cannot find an approved source.
Worker may: Tag it, gather the approved references, and send an already-approved factual reply only when the written rule permits it.
Worker must not: Do not promise an outcome or change an order, account, price, policy, or delivery expectation.
Worker may: Record the timing signal, gather facts, and route it through the approved queue.
Worker must not: Do not invent a deadline, confirm a breach, or promise a fix, refund, replacement, or exception.
Worker may: Preserve approved references, prepare a neutral draft if allowed, and ask the named owner for a decision.
Worker must not: Do not make the decision, change a record, or send an unapproved commitment.
Worker may: Preserve the message, apply the urgent tag, and use the named incident route.
Worker must not: Do not investigate independently, collect passwords or recovery codes, make admissions, delete records, or treat it as routine work.
These examples show a first routing decision, not a final answer. They do not set a response target, remedy, service level, security process, or policy. On smaller screens, scroll the table sideways to read every field.
| Fictional request | Customer effect | Priority route | Safe action | Held action | Owner route | Approved update route | Escalation trigger |
|---|---|---|---|---|---|---|---|
| Fictional billing question: an unfamiliar invoice charge | The customer may be worried about a charge and need a clear next step. | Restricted — owner review; use the urgent route if the written fraud trigger applies. | Record the ticket and invoice reference, check visible billing status, and use approved neutral wording only if permitted. | Confirming fraud, reversing a charge, issuing a refund or credit, changing payment details, interpreting tax, or promising an outcome. | Billing or finance operations owner; named security route for a suspected compromise. | Approved billing acknowledgement or owner-approved message. | An unfamiliar or duplicate charge, compromised payment method, or a charge tied to an unknown account. |
| Fictional account-access report: an unexpected MFA prompt | The customer may be locked out or may be reporting possible account compromise. | Urgent incident route when the written compromise trigger applies; otherwise restricted — owner review. | Preserve the ticket, account reference, timestamp, and error text; use approved public reset guidance only if the process permits it. | Asking for a password or recovery code, or changing email, MFA, permissions, identity fields, recovery data, or account ownership. | Security or incident owner; named system-owner backup for routine access cases. | Approved security acknowledgement or the qualified owner's update. | Unexpected MFA prompt, unfamiliar login, account-takeover report, identity mismatch, or another incident-plan signal. |
| Fictional safety report: a product became hot and caused a small burn | The customer may have experienced harm, and other customers may be at risk. | Urgent incident route. | Preserve the report and approved references, collect only intake facts required by the safety process, and notify the named safety owner. | Diagnosis, safety or medical advice, admissions, compensation, replacement or refund approval, recall announcements, or public statements. | Product safety, risk, clinical, or qualified operations owner named by the business. | Approved safety acknowledgement or owner-approved message only. | Injury, illness, unsafe behavior, a hazard, possible ongoing harm, or another safety-plan signal. |
Copy this into the business's approved system. If the source, owner, or approved message is missing, hold the action.
CUSTOMER REQUEST PRIORITY MATRIX Covered queue: Matrix owner: Approved taxonomy, SOP, and response-library source: Incident, safety, security, legal, and after-hours routes: Last tested and next review date: Request category and plain-language definition: Visible trigger and approved source: Priority route: [Routine / Time-sensitive / Restricted — owner review / Urgent incident route] Customer effect to record: Worker may safely: Worker must not: Required references and safe evidence: Primary owner and backup: Customer-update owner and approved message route: Written internal target or coverage-rule source: Escalate or re-route when: Final decision record: QA reviewer, sample reference, correction owner, and recheck date: Use the business's approved system and safe references. Do not paste passwords, recovery codes, full payment-card details, medical details, or unnecessary customer data here. This matrix classifies and routes a request; it does not approve a refund, price or policy change, access change, security decision, legal response, or customer promise.
The full matrix stays visible and selectable. Nothing is uploaded or saved.
This setup exercise does not replace service terms, contracts, security procedures, privacy controls, safety processes, legal advice, or emergency procedures.
Stop, hold the action, and use the more restrictive route when a ticket includes money, a customer commitment, an account or identity change, a policy exception, a security signal, a threat, safety concern, legal wording, or an unclear source.