Reporting issues to Adobe is crucial to everyone involved. Adobe needs to know directly from the customer when something is wrong or they are doing something that impacts their organization. And you the IT admin, deserve to be heard.
There are many ways to report an issue. The broader this issue is reported, the more visibility. And of course, the more of your peers that also report the issue the larger the influence. The more reports of the issue the more likely the issue will get bumped up on the list to fix and address.
Whenever possible try to target the communication to the specific product team. Most product teams have Twitter accounts. For instance if you have a grievance with Flash for instance, you could tweet to @AdobeFlash. But you might also include Adobe’s main Twitter account @adobe and the Support organization, Adobe Customer Care: @Adobe_Care
Most product teams additionally have forums. If the issue is with Flash Player then you might want to post here:
If you find a bug within an Adobe product you can file a bug here:
Most larger organizations have Adobe Account Executives that should be contacted when there are significant issues with the software or services that their organization have paid for. Organizations that buy from Channel Resellers often have an Adobe-centric rep and/or have a contact/partner back at Adobe that can help escalate issues or get answers.
Although most IT admins I know dislike calling any support organization, it a formal way to record the issue. Adobe’s Support organization has been getting more and more Enterprise-centric training in the last year. Depending on your level of your support contract you may indeed be on hold for longer than you would like to be. Nobody likes being on hold but reporting an issue to Support can often go a surprisingly long way.
In addition there are two sites that might be worth visiting:
When voicing a complaint or issue to Adobe or (any software vendor for that matter) I’d recommend doing the following:
1) State who you are, where you are, and what organization you represent. Being anonymous may be easier and “safer” but context helps for many reasons. It identifies the type of organization that is affected and the location and can even invoke more empathy and helps in storytelling. Imagine this internal conversation from three reports that follow this method: “A college in New Hampshire, a school district in Houston, and a newspaper in Berlin are reporting this issue. All IT admins. So it widespread and real.”
2) Be specific yet concise. Provide as precise and specific info about the issue but it is not necessary to always provide a log on a first post if it is not obvious that the log details would be helpful. If engineers get involved and need that level of detail, they’ll ask.
3) Define the impact. State the number of affected users, the actual cost to your business in hours, dollars, etc. If production deadlines are at risk, state that. Provide context. Example: “3 computer labs, a total of 63 Macs are impacted. This is preventing students from completing mid-term projects.”
4) Be respectful. A post that ends with “Thank you for addressing this issue for my organization.” is likely to go further then “You guys don’t give a crap about your customers and you won’t fix this anyway because YOU DON’T CARE ABOUT IT ADMINS!!!” There are no robots on the other receiving end, just humans with feelings and emotions. Take a moment and reflect on how you respond when your internal customers, students or clients are negative.
I’ve presented a lot of info and links that might be a bit too much to digest all at once, but the main thing to remember is: be heard.
Jody Rodgers | Sr. Product Manager | Enterprise + Volume | Digital Media | Adobe Systems