Triage a Customer Request

Turn an incoming customer request into a grounded view of what is happening, how quickly it requires attention, who should own it, and what the customer should hear next.

Use the team's actual support policies rather than inventing generic severity labels.

1. Understand the request

Read the complete available thread or record.

Identify:

• customer's question, request, or symptom;
• affected workflow;
• affected users or scope;
• timing and duration;
• relevant environment;
• exact error text where useful;
• previous troubleshooting;
• workaround, if known;
• what the customer needs now;
• emotional or communication context when relevant to tone and handling.

Preserve the customer's own wording when it materially improves investigation, search, or communication.

Confirm:

• account;
• channel;
• entitlement;
• applicable support policy;
• SLA where applicable;
• relevant routing rules.

Use the team's accepted:

• categories;
• priority definitions;
• severity rules;
• SLA;
• entitlement model;
• routing model.

If those definitions do not exist or cannot be verified, describe impact and urgency plainly rather than inventing a P1-P4 or equivalent classification.

2. Gather only context that can change triage

Use approved sources such as:

• support history;
• account notes;
• product documentation;
• help-center content;
• known-issue records;
• team discussions;
• project or engineering tracking.

Check for:

• related open requests;
• known issue;
• approved workaround;
• duplicate ticket or issue;
• recent relevant resolution.

Preserve source links and recency for important evidence.

Do not turn initial triage into a complete customer-research exercise.

Pull additional context such as:

• customer goals;
• plan;
• renewal;
• product usage;
• stakeholder relationship;
• commercial context

only when it could materially change impact, communication tone, ownership, entitlement, escalation, or next action.

3. Assess impact and urgency

Separate observed facts from assumptions.

Consider:

• who is affected;
• how many users or workflows are affected;
• how blocked they are;
• whether critical work can continue;
• whether a workaround exists;
• workaround quality;
• duration;
• recurrence;
• whether the issue appears to be spreading;
• accepted contractual or service obligations;
• time-sensitive customer dependencies.

Customer value or commercial importance may inform account handling where policy allows, but it must not override security, privacy, fairness, incident, entitlement, or SLA requirements.

Do not inflate severity with unsupported revenue, churn, executive, or contractual claims.

4. Route through the accepted policy

Recommend:

• category;
• priority or urgency;
• owner;
• response deadline;
• exact next action

using the organization's accepted policy.

Suspected:

• security incidents;
• privacy exposure;
• data loss;
• legal issues;
• regulated-data issues;
• active service incidents;
• other urgent specialist cases

must be routed immediately through the organization's accepted specialist or incident path.

Do not delay urgent routing to complete routine triage documentation.

5. Deliver the triage result

Provide:

Summary

A one-line description of the request and current state.

Customer and impact

State the affected customer/account, verified impact, urgency, and supporting evidence.

Classification

Provide the recommended category and, when the team's model supports it, priority or severity with reasoning.

Existing knowledge

State:

• known-issue status;
• workaround status;
• duplicate status;
• related issue or ticket when available.

Ownership and action

Specify:

• recommended owner;
• exact next action;
• response or decision timing under the accepted policy.

Information gaps

List only questions or missing evidence that could materially change routing or response.

Customer response

When useful, provide a concise initial customer response appropriate to the known facts.

Do not promise a fix, ETA, refund, product change, or outcome without authority.

6. Route specialist follow-up without duplicating it

When the next task is obtaining and communicating a reliable answer, route to the customer-question research workflow.

When another team needs a complete customer-impact package, route to the customer-issue escalation workflow.

When technical reproduction and an engineering issue are required, route to the appropriate bug-research/reporting workflow.

Keep triage focused on classification, routing, urgency, ownership, and immediate communication.

7. Apply only authorized actions

Treat these as separate actions:

• drafting a response;
• sending a response;
• changing priority;
• assigning an owner;
• merging a duplicate;
• changing ticket state;
• updating a customer record;
• filing or modifying an engineering issue;
• escalating to another team.

Follow active scoped permission for the exact record, destination, and action.

Verify completed changes where possible.

8. Preserve the accepted triage method

After the team confirms categories, signals, routing, SLA interpretation, and response patterns, preserve the reusable method.

A queue workflow may surface new or changed requests using named rules.

It should stop and request human review when:

• customer identity is ambiguous;
• impact is unusual;
• sensitive content appears;
• policy applicability is unclear;
• entitlement cannot be established;
• evidence conflicts;
• the request falls outside accepted categories;
• urgent specialist handling may be required.