Read Zendesk photo attachments before your reps open them

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.