تجاوز إلى المحتوى
جرّب المرجع الدورة المحفوظات
العربية
← كل playbooks دعم العملاء

playbook

Find what the queue is really about

Cluster a flood of tickets by the underlying issue, rank the top problems by volume with an example each, and flag which one is a bug to escalate instead of answering fifty more times.

متوسّط ~30 min

متى تلجأ إلى هذا

The queue has hundreds of tickets and answering top-to-bottom would eat the week while hiding the real story. Forty people describe the same broken thing forty different ways, so the eye sees forty problems where there's really one. This system reads the whole pile at once, clusters by the actual issue rather than the words people used, and ranks the problems by how many customers hit each — so you spend the day on the thing that's hurting the most people, and catch the one that's a bug, not a stream of complaints to answer.

جهّز هذا أولًا

  • A ticket export as tickets.csv — at minimum a subject and body column; a date and channel column help. Scrub names and emails to [customer] before you upload.
  • Roughly how many tickets you're handing it, and the window (last 48 hours, last week), so the counts mean something.
  • A one-line note on anything you already know is broken, so Claude can confirm or challenge it rather than rediscover it.

الـ workflow

  1. Have Claude read the export and describe the shape

    Before clustering, confirm Claude actually parsed the file — row count, columns, date range. A silent half-read of a CSV gives you confident clusters built on a third of the data.

    أنت تطلب 
    Read tickets.csv. Tell me how many rows you loaded, which columns you're using as the subject and the message, and the date range covered. Don't cluster yet — I just want to confirm you have the whole file.

    ما تحصل عليه A quick confirmation — "612 rows loaded, using subject and body, dated May 28–June 4." If the row count is far off from your export, you catch the truncation before it skews everything.

    Always make a tool prove it read the whole file before you trust a summary of it.

  2. Cluster by the underlying issue, not the wording

    This is the whole game. Thirty ways of saying "I can't log in" is one issue, not thirty — so you have to explicitly tell Claude to group by root problem, or it'll cluster on surface phrasing.

    أنت تطلب 
    Group these tickets by the UNDERLYING issue, not the customer's wording — treat 'login broken,' 'can't sign in,' and 'password reset loops' as one group if they're the same root problem. Give me the top 5 groups ranked by count, with the count and one real example ticket per group. Show me the long tail as a single 'everything else' count.

    ما تحصل عليه A ranked list — "login fails after password reset (47), invoice charged twice (31), shipping delay (22)..." — each with a sample ticket and a count, plus an "everything else: 64" so nothing's hidden.

  3. Separate the bug from the complaints

    A spike in volume can be a bug everyone's hitting, or just a busy week. Ask Claude to tell them apart, because the response is completely different — escalate the bug, answer the rest.

    أنت تطلب 
    For the top 5 groups, tell me which look like a recurring root-cause bug (same failure, many customers, started recently) versus normal one-off support. For any you call a bug, say what the shared trigger seems to be and how confident you are.

    ما تحصل عليه A split — "the double-charge group is a bug: 31 customers, all on annual plans, all since the May 30 billing run" vs. "shipping delays read as normal seasonal volume" — with a confidence note so you don't escalate a hunch as a fact.

  4. Write the escalation, ready to paste

    Hand engineering a tight, evidence-backed summary instead of fifty forwarded tickets. The count and the shared trigger are what get a bug prioritized.

    أنت تطلب 
    Write a 4-sentence bug report for the double-charge issue I can paste into our tracker: what's happening, who's affected and how many, the shared trigger, and 2 example ticket IDs as evidence. Neutral and specific, no speculation about the code.

    ما تحصل عليه A paste-ready escalation — the pattern, the count, the trigger, two example IDs — that lands on the right team's desk as a real signal, not noise.

    Verify the count against your raw export before you send it — the number is what makes engineering act, so it has to be right.

اجعله ملكك

  • **Roll it up over time:** run this weekly and feed the trends into the *Turn a month of tickets into a voice-of-customer report* playbook so triage becomes an early-warning system, not just a daily sort.
  • **Close the loop on the winner:** once a group is clearly the same question, send it to the *Build a help center from the questions you actually get* playbook so you answer the cause once instead of the symptom forever.
  • **Automate the read:** if you triage the same export every morning, save the prompts as a /triage custom command or a scheduled agent (see the Playbook's *Features* tab) that drops a ranked summary in your inbox before you open the queue.

انتبه إلى

  • Clustering is a draft, not a verdict — spot-check a few tickets in each group yourself, and always verify the headline counts against the raw export before anyone acts on them.
  • Scrub customer names, emails, and account numbers to [customer] before uploading the export — a ticket dump is dense with PII, and the patterns don't need the personal details.
  • Claude flags the candidate bug; a human owns the call to escalate. "Looks like a bug" with a confidence note is a lead to verify, not a confirmed defect to broadcast.

ستحصل في النهاية على A ranked map of what the queue is actually about — top issues by volume with examples, the one that's a bug clearly separated from the noise, and a paste-ready escalation — built in the time it would take to answer ten tickets blind.