Spot recurring customer complaints in Dixa and size them

I want an app that my support lead and I sit down with every couple of weeks to work out what customers are actually complaining about in Dixa. It is a shared review surface rather than an automation: nothing runs on a schedule, we open it together, pick a period, and work through what comes back.

The main screen starts with a date range picker, defaulting to the last 14 days. When a period is selected, the app uses the Dixa Search conversations with filters operation to pull every conversation in that window, and does the same for the immediately preceding window of equal length so we have a baseline to compare against. For each conversation in the current window it also calls List ratings for a conversation and keeps the satisfaction score where one exists. Let me optionally narrow the pull by queue, channel, or existing tag before I analyze anything.

Below the picker is the theme board: one card per theme showing the theme name, a one or two sentence description, the number of conversations in it, the change against the previous period as both a count and a percentage with a New label when there is no prior record, and the average satisfaction score across that theme's conversations along with how many ratings it is based on. Let me sort by volume, by lowest satisfaction, or by a combined priority that surfaces the themes that are both high volume and low rated, which is the view we care about most. Clicking a card opens a detail view with the full description, the representative quotes, and the list of underlying conversations showing subject, date, rating, and a link back into Dixa.

An Analyze this period button starts a background agent. The agent reads the actual transcripts using List messages for the conversations in the window, clusters them into a small set of named themes, roughly five to twelve, and for each theme writes a short plain-language description and picks two or three representative customer quotes as evidence. Quotes must be taken verbatim from the customer's own messages, not from agent replies, and each quote records the conversation it came from. The agent records which conversation ids belong to each theme and writes all of this back into the app, so the theme board renders from stored results rather than from a live run. Show progress while it works, and keep the previous analysis on screen until the new one is ready.

Before it clusters, the agent must read the app's record of themes filed in previous sessions and match its new groupings against them by meaning rather than by exact name, so that checkout errors and payment failures at checkout are recognized as the same theme. Any theme that was already filed is never proposed as a new theme to file. It appears instead in a separate Already tracked section showing the existing issue, this period's updated conversation count, and whether it is growing or shrinking. This is the rule I care most about: we run this every couple of weeks and I do not want a duplicate issue created every time.

For the trend numbers, prefer the stored analysis of the previous period when we have already run the app on it. When there is no stored prior analysis, have the agent also assign the previous window's conversations to the themes it just named, so even the first run shows a real comparison instead of marking everything as new.

Each theme card carries three actions. File to Linear uses Create Issue to open an issue in a team I choose, using List Teams to populate the team picker, with the theme name as the title and a description containing the theme summary, the representative quotes, the conversation count, the average satisfaction score, and the date range reviewed. Once the issue exists, the app stores its key, url, who filed it, and when, marks the card as filed with a link to the issue, and drops that issue link onto every conversation in the theme using Add internal note so agents working the queue can see the fix is tracked. Tag these conversations applies the theme name across the underlying conversations using Bulk tag conversation. For themes in the Already tracked section, replace the file button with a Post update action that uses Add Comment to Issue to append this period's count and trend to the existing issue.

Persist two things. Per period, store the analyzed themes with their descriptions, quotes, conversation ids, counts, and ratings, so reopening a period we already looked at shows the stored result instantly with a re-analyze option. Across periods, store the filed-theme registry that powers the deduplication described above. Filing, tagging, and noting are shared team state visible to everyone who opens the app, each stamped with the name of whoever took the action. Ask for confirmation before tagging or adding notes, since those write into Dixa where agents will see them. Dixa rate limits requests, so page through conversations and fetch ratings and messages at a steady pace rather than firing everything at once, and show the user roughly how far along the analysis is.