Screenshots in Discord Tickets: What the AI Reads, What Survives

So much of real support is somebody posting a picture of the thing that is broken. The error dialog, the payment page, the receipt, the screen that will not load. It is usually more useful than the sentence attached to it, and it is the one part of a ticket that is not text.

Which means every system in the chain treats it differently, and almost none of that is written down anywhere. Here is what happens to a file between the member dragging it in and you opening the archive a year later.

Can a Discord ticket bot read a screenshot?

Short answer: ours does, properly. When the person who opened a ticket posts an image, it is not logged as "user sent an attachment" and passed over. The file is downloaded, checked, and handed to the model as a picture alongside the text, so the reply can talk about the error message in the corner of the screen without the member having to type it out.

That is worth stating plainly, because "supports attachments" usually means the opposite: the file is stored and shown to your staff, which is useful and is not the same thing. Ours does that too, and then reads it.

A PDF is read as pages rather than as extracted text, so a table or a diagram inside one survives. An animated GIF is read as a single still frame, which is fine for a screen recording of an error and useless for anything that depends on the motion.

One limit surprises people: only the opener's files go to the AI. A screenshot posted by staff is stored, shown and kept in the transcript, but the AI never sees it, because the AI only ever answers the person who opened the ticket. That is the same rule that decides who the bot treats as staff.

What happens to a file the moment it is posted?

Four steps, all of them inside a few seconds, none of them visible to the member.

The checking step is stricter than it looks. The bot reads the first few bytes of the file to work out what it really is, rather than trusting the file name, so renaming screenshot.heic to screenshot.png does not get it through. That sounds pedantic until you know why it is there: a file whose label disagrees with its contents makes the whole request fail, and the member would get no answer at all rather than an answer that ignores one file.

The resize step matters more than any of this for the quality of the answer. Images above roughly four million pixels are scaled down before they are read. A normal phone or desktop screenshot sits comfortably under that. A photo of a screen, taken on a phone, usually does not, and a twelve megapixel photo loses more than half its width on the way in. The picture is still read, but small text in it may no longer be legible.

Why does the bot ignore a file sometimes?

Because it could not use it, and this is the honest limit worth knowing before you tell your members anything.

A file is skipped when it is a format outside the list above, when it is over the size cap for its type, when it is the sixth file in one message, or when the download fails. The AI then answers on your text and the files that did survive. It does not say "I could not read one of your files".

Even then the notice is generic. It says the message could not be sent to the AI, not which file was the problem. Skipping one file keeps the rest of the answer alive, where refusing the whole message would leave a member staring at an error, so the design is defensible. It still means the most confusing outcome in the system is an answer that quietly ignores the screenshot, and the member cannot tell that apart from an answer that read it and was wrong.

The practical version for your staff: if a member says "as you can see in the image" and the reply does not engage with the image, the file was probably skipped rather than misread. Ask them to repost it as a PNG or JPEG under 5 MB.

Why are the limits different when you train it?

Because a file in a ticket and a file you teach the bot are paying for two different things.

A file a member attaches is read inside one answer and then it is done. A file you upload through training is read once and kept, so it can answer questions for months. Because the ticket file is inlined into a single reply, the tighter caps stop one attachment from consuming a large share of that answer. Images sit at 5 MB on both sides, since the resize step already governs what they cost.

Worth knowing which of the two you are in, because the failure differs: in training, an oversized file costs more of your token budget rather than being skipped. That side is covered in how to train an AI ticket bot and how per-server AI memory works.

What does the transcript actually keep?

A record of the file, not the file. Every message in a ticket, including every attachment, is captured as it arrives, and the attachment is captured as three things: its name, its size, and its address on Discord. The picture itself is never copied to us.

That is invisible while the ticket is open, because the link works and the image renders. It stops being invisible later, and the reason is the way closing a ticket works here. Closing deletes the Discord channel, and the live message rows are deleted with it, which leaves the transcript as the only surviving copy of the conversation. Inside that archive, the images are addresses pointing back at a channel that no longer exists.

Open one and look at the link on an attachment. It carries an expiry stamp in the address itself. That is Discord's design rather than ours, and there is nothing on our side that can bring a picture back once its link stops answering. The file name and the size stay in the archive, so you can always tell that something was attached and what it was called.

The downloadable copies behave the same way. The self-contained HTML file opens years from now with its text intact, and still fetches its images from Discord at the moment you open it.

Where do screenshots not work at all?

Two places, both worth knowing before you promise a member anything.

The web widget is the one that catches teams out, because it is the surface where a visitor is most likely to have a screenshot ready. If a conversation there turns into something visual, moving it into Discord is the answer, which the widget's hand-off already does.

What should you tell your members?

Nothing, in most cases. People post screenshots without being asked and it works. The exception is a category where the picture is the point, like a payment problem or a bug report. There, one line in your ticket form earns its place.

That last one is the highest-value sentence you can add. It costs the member nothing and it is the difference between the AI reading the error text and reading a blurry rectangle.

Roughly half of all tickets across every server running this bot are resolved by the AI with no human involved, and getting a legible picture in front of it is a cheap way to move a category into that half.

None of this is unique to us in the parts that matter most. Any Discord ticket bot archives a link rather than a copy, because a link is what Discord hands it, so the advice about saving evidence yourself applies whichever one you run. What differs is whether the picture is read at all, and that is worth asking before you choose one.