A short customer message can hide several different jobs. The team may need to answer a question, restore a blocked workflow, find a known issue, involve Security, or simply acknowledge the impact while someone investigates.

Strawberry can read the complete thread, inspect relevant account and product context, search the support desk and project tracker, and prepare the route and first response in the same visible workspace. The priority still comes from the team's policy and the evidence, not a generic AI severity ladder.

Start with impact

Identify what the customer expected, what they observed, who is affected, how blocked they are, when it began, and whether a workaround exists. Keep exact error text and the customer's own description when they help search or investigation.

Want to try it?

Ask your Strawberry companion: “Triage this customer request using our actual priority, SLA, ownership, and escalation rules, then prepare the right next action and first response.”

Skill

Triage a customer request

Assess the request using the team's actual impact, priority, SLA, ownership, and escalation rules.

Once the team trusts the categories, priority rules, routes, and response pattern, save the method as a team skill so the queue is handled consistently. A Routine can prepare the next triage view when the trigger, sources, review point, and stop conditions are clear.

Check the context that changes the route

QuestionUseful evidence
Is this already known?Similar tickets, known issues, current project records, and documented workarounds.
How broad is the impact?Affected users, environments, product areas, and additional recent reports.
What obligation applies?The team's SLA, entitlement, account commitment, or accepted incident policy.
Who should own it?Root cause, required access, specialist knowledge, and the next decision.

Bring in account value, renewal, or relationship context only when it changes the response, obligation, or coordination. Triage should not become an indiscriminate customer dossier.

Prepare a decision, not a label

The triage result should make the next move clear: a concise issue summary, supported impact and urgency, category, suggested priority, duplicate or workaround status, owner, deadline, gaps, and a suitable initial response. If the team's rules do not support a formal priority, describe the urgency in plain language.

Security, privacy, data loss, legal, regulated, or active incident signals should follow the team's urgent specialist route rather than waiting for ordinary queue review.

Keep the actions separate

Drafting the response is not permission to send it. Reassigning a ticket, changing priority, merging a duplicate, and filing a product issue are also distinct actions. Strawberry follows the active permission for each record and destination and verifies any completed change.

Official Strawberry skill
Copy skill file Download skill file

Triage a Customer Request

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

1. Understand the request

Read the full thread or record. Identify the customer's question or symptom, affected workflow, scope, timing, environment, emotional state, prior attempts, and what they need now. Keep the customer's words and exact error text where they help investigation or search.

Confirm the relevant account, channel, and support policy. Use the team's actual categories, priority definitions, SLA, routing, and entitlement rules. If they are missing, describe impact and urgency plainly rather than inventing a P1–P4 system.

2. Gather only the context that changes triage

Use approved support history, account notes, product docs, help-center content, known-issue records, team discussions, and project tracking. Check for related open requests, an existing workaround, or a duplicate issue. Keep source links and recency visible.

Do not turn triage into a complete account research project. Pull in goals, plan, renewal, usage, or relationship context only when it changes impact, tone, ownership, or the next action.

3. Assess impact and route

Separate observed facts from assumptions. Consider who is affected, how blocked they are, whether a workaround exists, how long the issue has persisted, whether it is spreading, and any accepted contractual or relationship obligation. Customer value may inform attention, but it does not erase product, security, fairness, or SLA rules.

Recommend the category, priority or urgency, owner, and response deadline using the team's policy. Route suspected security, privacy, data loss, legal, regulated, or active incident cases immediately to the accepted specialist path.

4. Deliver the triage result

Provide:

  • a one-line request summary and current state;
  • customer, impact, urgency, and supporting evidence;
  • category, suggested priority, and reasoning;
  • known issue, workaround, and duplicate status;
  • recommended owner and exact next action;
  • gaps or questions that could change the route; and
  • a concise initial customer response when useful.

Use strawberry/customer-support-success/research-and-answer-a-customer-question when the next job is finding and communicating a reliable answer. Use strawberry/customer-support-success/escalate-a-customer-issue when another team needs a complete customer-impact brief. Use strawberry/product-engineering/research-and-report-a-bug when product reproduction and an engineering issue are required.

5. Apply only the accepted action

Drafting a response, sending it, changing priority, assigning an owner, merging a duplicate, updating a ticket, and filing an issue are separate actions. Follow the active scoped permission for each record and destination, and verify any completed change.

After the team accepts the categories, signals, routing, and response pattern, preserve them for later requests. A queue Routine may surface new and changed requests using named rules, but it should stop on ambiguous identity, unusual impact, sensitive content, or a case outside the accepted policy.