How to Write a Support Request That Gets Results

Hint: It’s all in the details.

We get it. You’ve hit a snag and want help fast. That’s what we’re here for.

But here’s the thing: The speed and quality of the help you get often depend on the quality of the information you provide. A vague “it’s not working” doesn’t give us anything to work with. But a detailed, specific question or report of the issue you’re experiencing is the fast track to resolution.

So, if you want the quickest, most efficient help possible, here are some things to think about as you’re writing your initial request. They might not all apply to you, but it’s better to over than undershare.

1. Tell us what went wrong.

Start with the basics:

• What are you trying to do?
• What did you expect to happen?
• What actually happened?

If something “doesn’t work,” explain how it doesn’t work. A clear problem statement saves a ton of time.

2. Retrace your steps.

Please include:

• Step-by-step instructions to trigger the issue.
• Whether it happens every time or only occasionally.
• Whether it used to work and has suddenly stopped — or has it never worked?
• If it used to work, when did it stop working?

If we can’t reproduce it, it’s unlikely that we’ll be able to fix it.

3. Who else is affected by the issue?

• Does this happen to everyone or just you?
• If it happens to everyone, are all of you:
  • Working on the same network?
  • Working in the same region?
  • Using the same device and browser?
• Do you have multiple Cloudinary accounts or are you a user on multiple Cloudinary accounts? If so, please tell us which one you’re referring to in the support request.

4. Share some examples (the more specific, the better).

Instead of saying, “Some images don’t load,” link us to one that’s broken. Sharing a specific example from the get-go can speed things up dramatically.

For example, suspect a caching issue? Please show us:

• What you’re seeing.
• What you expect to see.

That way, we can compare it to what we see on our end.

5. Include technical and/or contextual information.

Are you using the UI? Let us know so we won’t send you an answer based on the API. 

Some of these would be helpful to know:

• Are you using the API or the UI?
• Are you using any SDKs or integrations? Which one(s) and their versions?
• What’s your product environment cloud name (e.g., prod, staging, dev)? Please share the actual cloud name rather than the display name.
  
  If you’re unsure, you can find it under the Cloud Name column in your Account Settings > Product Environments.
• What’s your OS, browser, and device information?
• Do you see an error message? Please share that with us.

The more technical context we have, the faster we can pinpoint the issue.

6. If you’re sharing code…

Screenshots of your code are hard to read, and impossible to test. Instead:

• Paste your code directly
• Or use a snippet tool like Gist or CodeSandbox.

7. Check your permissions.

If one person on your team can access a particular folder or share a collection and you can’t — it’s often a permissions issue. These links can help get you started:

• Role-based permissions for Programmable Media
• Role-based permissions for DAM
• Folder sharing permissions

8. Are you referencing our Documentation?

If you’re working through a page in our documentation or a knowledge base article, please link to that page. If something there doesn’t work, we want to know about it so we can fix it or add clarity.

9. Record your screen with Jam.dev.

We love video recordings. But you know what’s better than a video? A video with context.

A screen recording via jam.dev is like magic for Support teams. It includes:

• Console logs
• Network requests
• Device and browser information
• And more — all in one shareable link

It’s free, and saves everyone time.

10. If your request involves account changes…

We’ll do our best to help, but we need to verify that you actually own the account or are an authorized user before we can share sensitive information or make changes. Please include a support verification code, which you can generate from the Support Verification Code tab in your Account Settings > My Profile. We can’t make any changes or share information about the account without it.

Here’s a side-by-side example of how much difference the details can make:

“My uploads don’t work. Please fix asap.”

We don’t know what “doesn’t work” means. The file size could be too large for the plan you’re subscribed to. It could be a permissions issue. It could be an issue with the configuration of your credentials. It could be a combination of these or none. We just don’t know with the information that was shared. So we’ll have to write back to you asking for additional information.

“I’m using the Node SDK (v1.2.3) to upload images via unsigned uploads. The images are under 2MB, which should fit in the allowance of the (free, plus, advanced, etc.) plan. They are all jpg or png. The issue happens in production, but not locally. 

I’m following <link to documentation> step by step. Everything worked until last night when uploads started failing with a 401 error. 

Here’s a jam.dev link showing my workflow. [insert link here]

The name of my product environment is <my-product-environment>. I’m the master admin on the account. My colleague who has the role of admin isn’t experiencing the same issue. 

I’m using Chrome, but the issue persists in Firefox and Edge as well, including incognito. I’ve tried clearing the browser cache, but no luck. I’ve attached one of the files that I’m unable to upload.”

This kind of ticket? We can usually jump straight to debugging. When we get back to you, we’ll likely have the answer, rather than needing to ask you for more information.

Good support starts with good communication. We want to help you as quickly and effectively as possible. The more context and detail you share upfront, the faster we can get you unblocked and on your way to building cool things.

Got questions? We’re here to help.

Submit a support request here.