Notify Your Team of Trending Support Topics (Before the Flood)

The fix isn't a better dashboard nobody watches. It's a small, boring background agent that watches the queue for you and speaks up the moment one topic starts spiking. This post walks through exactly that workflow on Macha: a scheduled agent that reads your Zendesk tickets on a recurring interval, compares the current mix against what's normal, and drops a Slack alert into your ops channel when something is clearly trending — so you find out from a bot, not from an angry escalation.

Macha is an AI agent layer that sits on top of the helpdesk you already run (Zendesk, Freshdesk, Gorgias, Front) and wires it to the rest of your stack. So this isn't a separate analytics product to log into — it's an agent living next to your tickets, firing into the Slack channel your team already has open.

What "trending" actually means here

Before building anything, it's worth being precise about the goal, because "trending topic detection" gets oversold. A good spike alert answers three questions the instant it fires: what changed, where it's concentrated, and whether it's still accelerating. That framing comes straight from the support anomaly-detection playbook — teams that get this right build a baseline by day-of-week, hour, and seasonality, then alert on concentrated deviations rather than on raw volume. Twelve tickets at 9am Monday might be normal; twelve tickets about one error string in two hours is not.

So the agent we want isn't "count the tickets." It's:

1. Pull the last slice of tickets from Zendesk.
2. Cluster them by what they're actually about (the model reads subjects and descriptions, not just tags).
3. Compare each topic's current rate to its normal rate.
4. If one topic is both high and concentrated, raise a clearly-worded alert with the common thread and a suggested owner.

Steps 2 and 3 are where an AI agent earns its place — it reads unstructured tickets and groups "can't log in," "login broken," and "502 on sign-in" into one cluster that a keyword report would scatter.

The workflow at a glance

Here's the use case as a Macha agent. It's deliberately small — two connectors, one schedule.

A real fire looks like this. The hourly run pulls the last two hours of tickets, the agent notices "Login issues" up ~300% — 12 tickets versus a normal ~3 — spots that the common thread is a "502 error" on the login page, and posts:

🔥 Trending Topic Alert "Login issues" is spiking — 12 tickets in the last 2 hours (normal: ~3). Common thread: customers reporting a "502 error" on the login page. This may indicate a service issue. Consider checking with engineering.

That message is the whole point: it lands in Slack with what, how much, and what to do next, while it's still a dozen tickets and not a hundred.

Building it: the scheduled trigger

The engine behind this is Macha's scheduled (cron) trigger — the same feature that lets any agent run on a recurring interval instead of waiting for a ticket event. You attach it to your trend-monitor agent and pick the cadence.

A few product facts that matter for this use case (all current behavior):

• Cadence is hourly, daily, or custom cron. The minimum interval is 1 hour — there's a hard floor by design, so this is early warning, not real-time streaming.
• Guardrails are built in: a 24-runs-per-day cap and a concurrency limit so a misconfigured schedule can't stampede.
• Auto-disable on failure: if a scheduled trigger fails 5 times in a row, Macha disables it and emails you — a runaway loop won't silently burn credits.
• Plan limits: scheduled triggers are a Professional and Enterprise feature — Professional includes 3, Enterprise 20. (See pricing.)

You can see all of an org's scheduled agents and their cadences in one place, which is handy once you're running a trend monitor alongside other periodic jobs.

If you've never wired a trigger before, every Macha trigger — scheduled, Zendesk ticket events, Slack mentions, custom webhooks — is picked from the same panel on the agent's config page.

Building it: the agent's instructions

The schedule decides when; the agent's instructions decide what good looks like. This is a read-and-report agent, so it gets Zendesk Search Tickets and Slack Send Message as tools — and nothing that writes to a customer. The instructions carry the judgment:

• Scope the read. Tell it to search the recent window (e.g. tickets created in the last ~2 hours) so each run looks at fresh volume.
• Define normal. Give it the baseline you actually know — "typical volume for login is ~3/hour; shipping runs ~8/hour" — or have it pull a wider window to estimate the baseline itself. The honest version: an LLM eyeballing counts is a heuristic, not a control chart (more on that below).
• Set the bar to alert. "Only post if a single topic is both clearly elevated and concentrated — a meaningful multiple of normal, not noise." This is what keeps it from crying wolf at every quiet fluctuation.
• Make the alert useful. Require the message to name the topic, the count vs. normal, the common thread (the shared phrase or error), and a suggested owner ("consider checking with engineering").

That last instruction — common thread + suggested owner — is the difference between an alert people act on and an alert people mute. "Tickets are up" gets ignored; "12 login tickets, all '502 error,' check eng" gets someone moving.

Pair it with Studies for a real baseline

The scheduled agent is your smoke detector — cheap, always-on, deliberately twitchy toward early warning. It is not a rigorous statistical baseline, and you shouldn't pretend it is. When you want the defensible picture — "what are the genuine top trends across thousands of tickets, with real percentages" — that's a job for Macha Studies, which runs an AI analysis across your whole ticket history and returns charts you can trust.

The two work together: run a Study monthly to establish what "normal" topic mix and volume actually are, then feed those numbers into the scheduled agent's baseline so its hourly alerts fire against reality instead of a guess. Smoke detector for the moment, Study for the season.

What it costs to run

Macha bills in credits per AI action (the default GPT-5.4 Mini model is 1 credit per action; heavier models cost more, lighter ones less — 0.5 to 9 by model). For this agent, a run costs roughly: one Zendesk search + the model reasoning over the batch + (only when it fires) one Slack message. Most hourly runs are quiet and cheap; the spend is dominated by the read-and-reason step, not the alerts.

The thing to size for is that a scheduled trigger runs on every interval whether or not anything's wrong — 24 runs a day at hourly cadence. That's the trade you're making: a small, steady cost to never miss the early signal. Start it on a 7-day free trial, no credit card required, watch a day of runs, and tune the cadence and search window to fit your real volume.

Watch-outs — when this is the wrong tool

This pattern is genuinely useful, but be honest about its edges:

• It's hourly, not instant. The 1-hour floor means a topic can climb for up to an hour before the next run sees it. For a true real-time page (full outage, payment processor down), back this with status-page monitoring and event-driven triggers — don't make an hourly cron your only outage detector.
• LLM counting isn't anomaly detection. The model reads and clusters beautifully, but "is 12 a spike vs 3" is a judgment call it makes from your guidance, not a Z-score. For statistically tight thresholds, compute the baseline with Studies (or a custom tool) and tell the agent the number — best practice is to correlate more than one signal before escalating.
• Tune for false positives. A too-eager bar floods Slack and gets muted; a too-strict bar misses the early window. Review the alerts it sent each week and adjust — alert quality is a tuning loop, not a set-and-forget.
• It needs context to be smart about seasonality. Monday mornings and post-launch days are supposed to be busy. Put known spikes (launches, billing runs, maintenance) in the instructions so it doesn't alert on expected volume.
• Plan gating. Scheduled triggers are Professional/Enterprise, and Professional caps you at 3 — budget this one against your other periodic agents.

If your queue is tiny, you'll see trends with your own eyes and this is overkill. It earns its keep once volume is high enough that no single person sees the whole queue at once — which is exactly when spikes hide.

FAQ

How quickly will I find out about a spike? Within your interval. At the hourly minimum, the agent sees new volume on the next run — so worst case ~60 minutes, typically sooner. For instant outage detection, pair it with event-driven triggers and status monitoring rather than relying on the schedule alone.

Does it work with Freshdesk, Gorgias, or Front instead of Zendesk? The pattern is the same — a scheduled agent that reads recent tickets and posts to Slack. The example here uses Zendesk's Search Tickets action; Macha's other helpdesk connectors expose equivalent reads. See the docs and the Macha-on-Zendesk overview.

How does it know what "normal" is? You tell it — either a baseline you already know, or one you compute from a wider ticket window or a Studies run. The agent then judges each run against that baseline. It's a heuristic, so tune the threshold over the first week.

Will it spam my Slack channel? Only if you set the alert bar too low. The instruction to fire only on topics that are both clearly elevated and concentrated is what keeps it quiet on normal days. Review the alerts weekly and tighten or loosen from there.

Which plan do I need? Scheduled triggers are on Professional (3 included) and Enterprise (20). The pricing page has current details.

Start small

Pick your single most outage-prone topic — login, checkout, a flaky integration — and build one agent that watches just that, hourly, into one Slack channel. Once the team trusts its alerts, widen the scope. Start a 7-day free trial, no credit card required, connect Zendesk and Slack, and put a smoke detector on your queue. The first time it warns you an hour early, it's paid for itself.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.