# Read Zendesk photo attachments before your reps open them

> Every 15 minutes we look at new support tickets that arrived with photos, describe the damage or the error on screen, and leave a private note for your rep.

- Workflow type: agent
- Services: Zendesk, Replicate, Slack
- Categories: Customer Support, Operations
- Published: 2026-08-09

## What it does

- Checks your support queue every 15 minutes and picks out only the tickets that arrived with photos attached.
- Describes each picture in plain language: what the item is, what damage or defect is visible, and what error message a screenshot is showing.
- Leaves the description on the ticket as a private internal note and tags it, so your saved views can filter on things like damage-confirmed or screenshot-error.
- Sends a Slack alert when a photo shows severe damage or something that looks like a safety problem.

## What you'll need

- A Zendesk account with agent or admin access, so the workflow can read tickets and add private notes.
- A Replicate account, which is what actually looks at the pictures.
- A Slack workspace and a channel where severe damage and safety alerts should land.
- Support tickets where customers attach photos, such as returns, warranty claims, and damage reports.

## Prompt

Every 15 minutes, look at the Zendesk tickets that recently arrived with photo attachments and tell the support rep what is in the picture before they open it. Use a cron trigger running every 15 minutes.

Start with Zendesk List Tickets, sorted newest first, and keep only the tickets created or updated since the previous run. For each candidate, use Show Ticket for the subject, requester, and current tags, and List Ticket Comments to walk the comment thread, because attachments live on comments rather than on the ticket itself. Inspect each comment's attachments and keep only image files, judged by content type and file extension such as jpg, jpeg, png, heic, gif, or webp. If a ticket has no image attachments, skip it completely and do not modify it in any way.

Zendesk attachment content URLs are not freely public, so a vision model cannot fetch them directly from Zendesk. Download the attachment bytes using the authenticated Zendesk connection, then upload each image to Replicate with Create File and use the URL that comes back as the model input. From the Replicate documentation, verbatim: "Prediction input files are passed as public HTTP URLs or data: URIs; upload private files first via POST /files and reference the returned URL."

Run a vision-capable model on Replicate with Create Prediction, passing the uploaded file URL along with an instruction to describe the image factually. Predictions are asynchronous, so poll Get Prediction until the status is succeeded, failed, or canceled rather than assuming the first response holds the output. Model inputs are model specific, so read the input schema with Get Model first if the correct field names are not obvious. If a prediction fails or times out, note that the image could not be read, then move on instead of stalling the whole run.

For each photo, write a short plain-language assessment covering three things: what the product or item appears to be, what damage or defect is visible and roughly how severe it looks, and, if the image is a screenshot, the exact error message, error code, or app screen shown. Stay factual and describe only what is visible. Do not speculate about who is at fault, whether a claim should be approved, or what caused the damage. If a photo is too blurry, dark, or cropped to judge, say that plainly instead of guessing.

Write the assessment back to the ticket with Zendesk Update Ticket as an internal note. This is a hard rule: the assessment must never be posted as a public reply, because the customer must not see it. When a ticket has several images, write one internal note covering all of them, numbered per image, rather than one note per photo. In the same update, add a tag that matches what was found, such as damage-confirmed, screenshot-error, no-damage-visible, or image-unclear, so the team's saved views can filter on it. Preserve the tags already on the ticket instead of overwriting them.

If any photo shows severe damage or anything that looks like a safety issue, for example a burnt, melted, or swollen battery, exposed wiring, signs of fire or smoke, leaking fluid or chemicals, or sharp broken glass or a visible injury, also post it to the designated Slack channel with Send a Message. Include the ticket subject, a link to the ticket, a one-line description of what was seen, and why it was flagged. Routine dents, scratches, and error screenshots do not warrant a Slack alert.

Do not reprocess the same ticket on later runs. Before assessing, check whether the ticket already carries one of the tags this workflow applies, and skip it if it does.

## How to customize

- Change how often it runs. Every 15 minutes suits a busy returns queue, while hourly is plenty for lower volume.
- Rename the tags to match the views your team already uses, or add your own for categories like wrong-item-shipped.
- Decide what counts as severe enough to alert on, and pick which Slack channel gets pinged.

## FAQ

### Will the customer see what the workflow writes?

No. The assessment is always added as an internal note that only your agents can see. Replying to the customer stays a human decision.

### What happens to tickets that do not have a photo?

They are skipped entirely. The workflow only touches tickets with an image attached, so the rest of your queue is left exactly as it was.

### What kinds of photos does this handle?

The everyday ones support teams get: a cracked or dented product, a damaged box, the wrong item in the package, or a screenshot of an error message. It describes what is visible and says so when a picture is too blurry or dark to judge.

### Does it decide whether to approve a refund or a warranty claim?

No. It describes what the photo shows so your rep can make that call faster. Approvals stay with your team.

### What if it describes something incorrectly?

Treat the note as a head start rather than a verdict. It is written to stay factual about what is visible, and it flags pictures it cannot read clearly instead of guessing.

Use this prompt in General Input: https://www.generalinput.com/prompts/read-zendesk-photo-attachments-before-your-reps-open-them