Find the customers stuck contacting support again and again

Build me an app that shows the people who keep coming back to support, not the ticket themes, so my team can finally break the loops. The unit on this board is a stuck human, not a topic. I want to open it for a weekly review and immediately see which individual customers have now explained their problem to us three or more times.

The main view is a ranked board of repeat contacters over a rolling thirty day window, and the window length should be adjustable from the UI. Build the list with Kustomer Search Customers to get customers active in the last thirty days, then for each one pull their conversations with Get Conversations by Customer and count them server side. Keep only customers with three or more conversations that started inside the window, and rank the board by contact count, breaking ties by the most recent contact first. Do not try to filter on conversation counts inside the search itself if that is awkward; pulling recently active customers and counting their conversations in the handler is the reliable path.

Counting rule, and this one matters a lot. Count only genuine new conversations, never one long thread. If a customer keeps replying inside a single conversation for three weeks, that is one contact, not three. Count distinct conversation records by their created date, and show each conversation's start date on the expanded row so a lead can sanity check the count without leaving the app.

Each row shows the customer's name and email, how many separate conversations they opened in the window, the span between their first and their latest contact written in plain language such as nineteen days, the subject line of each conversation, and whether anything of theirs is still open right now. Make the still open state visually obvious, since an open thread on a customer who has already contacted us three times is the most urgent thing on the board.

Opening a row lays that customer's threads out side by side, one column per conversation in date order, so a lead can literally see the same problem restated three different ways. Fill each column using Get Messages by Conversation for the back and forth and Get Notes by Conversation for the internal notes agents left behind, and use Get Conversation by ID for the status and assignment details on each thread. The internal notes are important context, because they usually show what support thought it had fixed.

Every row has a Diagnose this loop button that starts a background agent. The agent reads every one of that customer's conversations in the window, all the messages and all the notes, and works out what is actually still unresolved versus what support believed it had already resolved. It writes up its finding with direct verbatim quotes from the customer, a short account of what each previous attempt tried, and a recommended fix. It then posts that write up onto the customer's newest conversation using Create Note by Conversation, and the app shows the same write up in the expanded row for review. Show the agent's progress while it runs and store the finished diagnosis so it is still there on the next visit.

When a diagnosis points at a product or process defect rather than a one off mistake, a File in Linear action creates the issue. Let the lead pick the destination team from a picker populated by Linear List Teams, then use Create Issue with the diagnosis, the customer quotes, and a link back to the customer in Kustomer in the issue description. Store the mapping from customer to created issue in the app database so the row shows a filed badge with the issue identifier, and refresh the current state with Get Issue so the board shows whether engineering has started or shipped the fix.

Two more state rules. Skip customers whose repeat contacts are already covered by a filed issue, so the same person does not clog the board every week once we have acted on them, but still show them in a separate filed section with their issue status. And let a lead mark a loop as closed by hand once the customer has gone quiet, with the closed loops kept in their own view rather than deleted, so the team can see what it actually resolved. Persist the filed mappings, the stored diagnoses, and the closed markers in the app database.

One important constraint about Kustomer. Creating a message records an instance on the conversation timeline and does not deliver an outbound message to the customer, so this app must never try to reply to customers. Everything it writes stays internal, which means notes on conversations and nothing else.