The week's support requests, grouped by root cause.
Support digest is an AI agent for support ticket analysis. Every week it reads your support requests, groups them by root cause rather than wording, counts each group and names the customers. Then it finds the open GitHub issue tracking each problem, or says there isn't one, and posts one Slack digest, biggest group first.
- 16:00Schedule fired
- 16:00Read 22 requests from this week
- 16:01Grouped them into 9 root causes
- 16:01Searched and read open GitHub issues
- 16:02Posted digest · 4 groups tracked
Why do the same support issues keep coming back?
Because each request is answered on its own. Five customers describe one bug five different ways, each gets a polite reply, and the pattern never reaches engineering. Nobody has time to read the whole week's queue, group it and check what's already being fixed, so the loudest problem gets planned, not the biggest.
Without it
- Every request read alone, so patterns go unseen.
- Five customers report one bug before anyone connects them.
- No idea whether engineering already tracks it.
- Planning by whoever shouted loudest.
With Support digest
- The week's requests grouped by root cause.
- A count and the customers for every group.
- The open issue linked, or a plain 'none'.
- Biggest problems first, every Friday.
What does support ticket analysis find?
Four answers for every week of requests: what caused them, how often, who was affected, and whether engineering already tracks it.
Root causes
Requests grouped by what caused them, however each customer worded it.
How often
A count for every group, ordered largest first, with the week's total and its dates.
Who's affected
Every customer in each group, named once, so success knows who to update.
What's tracked
The open GitHub issue for each group, read before it's linked, or a plain statement that none exists.
How does AI support ticket analysis work?
Every run follows the same five steps, then posts one digest. GitHub is only read, and only the last step writes anything.
- 1
Finds your inbox table
The support requests you upload, with their columns checked.
- 2
Reads this week's requests
Monday to today, grouped by root cause, not by wording.
- 3
Searches the open issues
One list of open issues, then a keyword search per group still open.
GitHub - 4
Reads each match
Links an issue only if it describes the same problem.
GitHub - 5
Posts the digest
Biggest group first, each with its count, customers and issue.
Slack
- Fridays at 16:00, ahead of Monday's planning
- @support-digest what kept coming up this week?
- Run when your help desk calls its webhook after the weekly export
From one sentence to a weekly digest.
Describe the job, let Arclyx draft the agent, test it once on your real requests, create it, then read what lands in #support-digest. Every group says whether an open issue tracks it.
Paste the sentence. Arclyx picks the tools it needs and asks what it can't work out.
What should it do?
Every Friday at 4, read this week's support requests, group them by root cause, count each group and name the customers, find the open GitHub issue that tracks each one or say there isn't one, and post the digest to #support-digest, biggest group first.
- Tools it can use
- GitHub
- Slack
- Which repository tracks your issues?
- Our product repository, open issues only
It writes the instructions, and you sign in to each tool once. Nothing runs until you say so.
- Reading your description
- Writing the instructions
- Picking the tools
Support digest
- GitHub
- Slack
Fridays, 16:00
Try it once as a dry run. It reads your real tools, and what it would post is shown to you, not posted.
- Finds your inbox table
- Reads this week's requests
- Searches the open issuesGitHub · Search issues ×4
- Reads each matchGitHub · Read issue ×4
- Posts the digestSlack · Post
Once it's created, the output lands where you said, with a source for every item.
Five requests, from Customers A, G, H, I and J.
Tracked by #214: editing a schedule's time clears where its report is sent.
↗ example-a.com/issues/214Four requests, from Customers B, A, D and E.
Tracked by #187: mark an integration unhealthy when its sign-in fails.
↗ example-a.com/issues/187Three requests, from Customers L, A and D.
No open issue tracks this.
↗ example-a.com/support-inboxTwo requests, from Customers K and C.
Tracked by #231: cap how long one upload can take.
↗ example-a.com/issues/231
One digest, four teams.
The same Friday digest answers a different question for each team that reads it.
Support leads
Which problems are eating the queue, with numbers.
Product managers
What customers hit most, and which has no issue yet.
Engineering leads
Which open issues are costing support the most.
Customer success
Which of their customers keep running into the same thing.
How do you analyze support tickets with AI?
Export a week of support requests and give an AI agent the job of grouping them by root cause. It counts each group, names the customers and checks your issue tracker for what's already being fixed. You get the week's biggest problems in one message. In Arclyx that's five steps, starting with one sentence.
“Every Friday at 4, read this week's support requests, group them by root cause, count each group and name the customers, find the open GitHub issue that tracks each one or say there isn't one, and post the digest to #support-digest, biggest group first.”
- 1
Describe the job
One sentence: which week, which repository, and where the digest goes.
- 2
Upload your inbox
An export of your support requests as CSV. Arclyx reads it as a table.
- 3
Connect GitHub
The agent gets only tools that list, search and read issues, so it can't change one.
- 4
Watch a dry run
Optional. See this week's digest on your real requests before anything is posted.
- 5
Schedule it
Fridays at 16:00, or @mention it before planning.
Or start from one of these sentences
“Every Friday at 4, group this week's support requests by root cause and post only the groups with no open GitHub issue to #product.”
“On the 1st of each month, group last month's support requests by root cause and list the five biggest with their GitHub issues.”
“When I name a customer, list every request they sent this month, grouped by root cause, with the open issue for each.”
“Every Monday at 9, list last week's three biggest support problems with request counts and their GitHub issues in #planning.”
AI ticket analysis vs searching by hand.
Reading requests by hand and searching GitHub each cover part of the job. Here is what each one does, and doesn't, do.
| By hand | GitHub issue search | Support digest | |
|---|---|---|---|
| Groups requests by cause | If someone reads them all | No: it searches what you type | Yes, by root cause, not wording |
| Counts and names customers | With a tally sheet | No | Yes, for every group |
| Finds the open issue | Search for each one | Yes, by keyword, state and repository | Yes, read before it's linked |
| What you get | A spreadsheet | A list of matching issues | One Slack digest, biggest group first |
| Setup | An afternoon every week | None | One sentence |
Source: GitHub docs: searching issues and pull requests, checked 24 October 2026.
Is it safe to give an AI agent your support inbox and GitHub?
It reads your inbox table and GitHub issues, and writes only one message to Slack or your inbox. Every run is recorded and has a spend ceiling by default.
Every run is recorded
Every step, in order
Every run records the tools it called, with a short preview of each result. Only the person who started a run can open its content.
Every link, read first
Its instructions say to read an issue before linking it, and to mark a failed search, never call it 'no issue'.
What each run cost
Tokens and cost are recorded per run and per agent, next to your plan's limits.
A spend ceiling, on by default
Each run has a dollar ceiling unless you remove it. A run stops before it goes over it, and tells you.
It can
- Read the tables you can access in Arclyx
- List, search and read open GitHub issues
- Post to one Slack channel you name, message you, or email you
It can't
- Create, edit, label or close GitHub issues
- Change your tables
- Reply to a customer
- Email anyone but you
Support ticket analysis, answered.
What is support ticket analysis?
Reading a batch of support requests to find what keeps going wrong: which problems repeat, how often and for whom. Done by hand it means tagging every ticket. Support digest does it each week and ties each problem to the issue your engineers are tracking.
How does it group requests?
By root cause, not wording. 'Reports stopped after I changed the time' and 'no report this week since the schedule edit' land in one group. One-off account and billing asks, such as seat counts or invoices, are merged into a single admin group.
Does it create or edit GitHub issues?
No. It's given only GitHub tools that list, search and read issues. It can't open, label, comment on or close one, so filing a new issue for an untracked problem stays with your team.
How does it decide an issue matches?
It reads the issue before linking it, and links it only if it describes the same problem. If only a loosely related issue exists it says 'No open issue tracks this' and names the nearest one, so a weak match never passes as tracked.
What if a GitHub search fails?
It marks that group 'search failed', never 'no issue'. Arclyx runs GitHub searches one at a time because GitHub limits how fast you can search, and waits and retries when it's limited. If a search still fails, the digest says so.
Where do the support requests come from?
An export of your support inbox, uploaded to Arclyx as a CSV table with a customer, message and date column. Any help desk that exports to CSV works. It reads the rows from Monday to today.
Does it reply to customers?
No. It reads requests and reports to your team. Its one message goes to a Slack channel you choose or to you; it has no tool that reaches a customer. Support triage drafts replies to routine requests for a person to send.
Do I need to write code?
No. Describe the job in one sentence. Arclyx drafts the agent, you upload your inbox and sign in to GitHub once, and you can watch a dry run before you create it.
Agents that work well with it.
Build your support digest.
One sentence in, a working agent out. Join the beta and we'll set you up.