# Send yesterday's support tickets into your product analytics

> Every evening, yesterday's Zendesk tickets land in Segment as clean, categorized events, so you can see which product areas actually generate support.

- Workflow type: agent
- Services: Twilio Segment, Zendesk, Slack Bot
- Categories: Customer Support, Product
- Published: 2026-08-10

## What it does

- Collects every support ticket raised in the last 24 hours, once a day at 6pm.
- Leaves out spam, automated and system generated tickets, and anyone with no email address, so your analytics stay clean instead of filling up with noise.
- Sorts each ticket into a simple category (billing, bug, how to, cancellation or other) and sends it to your customer data platform, attached to the real person who raised it rather than an anonymous visitor.
- Posts an evening Slack summary with how many tickets went through and the breakdown by category.

## What you'll need

- A Zendesk account with permission to view tickets
- A Segment workspace, plus the specific source you want the support events to land in
- A Slack workspace and a channel for the daily summary

## Prompt

Every day at 6pm, push support signal into my product analytics so support friction ends up sitting next to product usage in the warehouse. Pull yesterday's Zendesk tickets, forward each one into Segment as an event attached to a known user, and finish with a Slack summary for my support lead.

During setup, ask me which Segment Source these events should go into, and collect that Source's write key. This matters: Segment tracking calls authenticate with a Source write key, not with the workspace Public API token, and the write key is issued per Source. Do not assume the Public API token will work for sending events. Also ask me which Slack channel should receive the summary.

Start with Zendesk List Tickets to get every ticket created in the last 24 hours. Sort by created date descending and page through with cursor pagination, stopping once you pass the start of the window. Side-load users on the request so each requester's email address comes back alongside the ticket, instead of making a separate lookup per ticket.

Use judgement to decide what deserves to reach the warehouse. Skip spam and anything automated or system generated: no-reply and mailer-daemon senders, monitoring and alerting bots, out of office autoreplies, bulk marketing blasts, and tickets opened by our own integrations rather than by a person. Skip any ticket whose requester has no email address, and never invent or synthesize an identifier to fill the gap, because a fake id quietly corrupts the user data in the warehouse. Keep a running count of what you skipped and why.

For every ticket that survives the filter, read the subject and normalize it into exactly one short category: billing, bug, how to, cancellation, or other. Fall back to the first part of the ticket description when the subject is uninformative, and choose "other" when the intent is genuinely unclear rather than forcing a ticket into a category it does not fit.

Then send two Segment calls per ticket, identify first so the user exists before the event lands. Use Segment Identify User for the requester, keyed on the requester's email address as the userId unless I tell you my product uses a different user id, with the email and name attached as traits. Follow it with Segment Track Event named "Support Ticket Created", carrying ticket id, subject, priority, status, channel and requester email as properties, plus the category you assigned. Set the event timestamp to the ticket's created date so events land at the time the ticket was actually raised rather than at ingest time.

Set a stable messageId on every track and identify call, derived from the Zendesk ticket id, for example "zendesk-ticket-<ticket id>-track" and "zendesk-ticket-<ticket id>-identify". Segment de-duplicates by messageId within a 24 hour window, which is what makes a re-run or an overlapping time window safe instead of double counting yesterday's volume.

Keep each event small. Truncate long subjects to roughly 200 characters and never attach the full ticket body, because the tracking API rejects any single event larger than 32 KB.

Finish by posting a Slack message to the chosen channel: how many tickets were sent to Segment, the breakdown by category, and how many were skipped for spam or automation versus a missing email address. Word it as "sent", not "delivered". A successful tracking call returns an empty 200 response, which only means Segment accepted the event for processing, not that it reached the warehouse or any downstream destination. If nothing qualified, still post a short note saying so, so the silence is never ambiguous.

## How to customize

- Change the 6pm timing or the 24 hour window it looks back over.
- Rename the event or adjust the category list so it matches how your team already talks about support.
- Send the summary to a different Slack channel, or add a priority breakdown next to the categories.

## FAQ

### Will this create duplicate events if it runs twice?

No. Every ticket is stamped with a stable identifier based on the ticket itself, so if the workflow runs again or the time windows overlap, Segment recognizes the repeat and ignores it rather than counting the ticket twice.

### What happens to tickets from people with no email address?

They are skipped, and the count shows up in your Slack summary. We never invent an identifier for someone, because a made up id would quietly pollute your analytics with fake users.

### Does this work if my Segment workspace is in Europe?

Yes. You pick your region when you connect Segment, and events are sent to the matching region.

### How does it decide what counts as spam or an automated ticket?

It reads each ticket the way a person would, looking at who sent it and what it says. Things like no-reply senders, monitoring alerts, out of office bounces and bulk marketing blasts get left out, and the number skipped is reported in the summary.

### Can I send tickets into more than one Segment source?

Each run sends into the one source you choose during setup. If you want the same tickets in a second source, copy the workflow and point the copy at that one.

### When will the tickets appear in my warehouse?

Once Segment accepts the events it forwards them on to whatever destinations and warehouse you have switched on for that source. How quickly they land depends on your own warehouse sync schedule rather than on this workflow.

Use this prompt in General Input: https://www.generalinput.com/prompts/send-yesterdays-support-tickets-into-your-product-analytics