Tiered Customer Support based on Users Experience.

[andrewdroth]

I would like to see a customer support system that relays your technical product support request to a representative that matches or exceeds  your experience.

Lately I've submitted software bugs/misbehavings and having responses from individuals whom either don't understand the issues, or assume I need help figuring out how to do something.

I've been using the software almost exclusively for 10 years, after that amount of time you have a pretty good idea of whether you've done something wrong, or the software is behaving poorly.

Perhaps it could be based on your Autodesk Community rating, or possibly by submitting documentation such as being a trained professional in the software.

I'm paying extra for this service, and I shouldn't need to feel frustrated by the response I get when trying to point out a flaw.

[DRoam]

Fortunately, I've not had the experience of working with an Autodesk support representative with sub-par knowledge of the software. However, what I often do experience is a representative who will not acknowledge the presence of a bug but instead wants to blame the behavior on my workflow. This is extremely frustrating.

I appreciate the effort to find a workaround for my current situation, but I don't appreciate the fact that no acknowledgment whatsoever is made that there is a bug in the software, and no indication is given that the bug will be reported to the Inventor team so it can be addressed. In the rep's mind, I need to get over it and perform however-many extra steps to make up for the bug. This is wrong, and representatives should be trained to respond properly to bugs by acknowledging and reporting them.

[andrewdroth]

I completely agree!

I just want them to say it's a problem with the software and that a workaround shouldn't be neccessary.

But more often than not, I'm given a workaround and the impression that it's just how it's going to be.

[dgorsman]

There needs to be some context there.  If the program is functioning as designed (even if that is personally considered inefficient) it isn't a bug, and possibly isn't considered a flaw depending on the context.  If you want the program to do something differently, then fine - but what about other users?  What happens if they want it to function the way it is designed?  Then AutoDesk gets into a problem of having to choose "winners" and "losers" and guess what: somebody will *always* be on the losing side of that decision.  Another user will be making this very same post arguing in the other direction.  Therefore we cannot be making arguments about what is or is not a bug or flaw based on our own personal preferences or workflows.

[andrewdroth]

I'm not talking about features or workflow issues. I'm talking about the software not behaving as it should (from a develpoment standpoint).

If I wanted things to work differently than they are designed to, I'd post that here, that is not what I use technical support for.

[DRoam]

I appreciate the input, @dgorsman, but I'm with @andrewdroth in reaffirming that we're not talking about workflow preferences here--we're talking about outright misbehaviors of the software.

A great example is related to a drawing bug I experienced a few weeks ago. I had a drawing with shaded views, and some of the parts in the view were not displaying the proper color. The exact same View Rep in the assembly itself dispalyed the proper colors. All of the settings were checked that should have made the Drawing View share the same settings as the View Rep in the Assembly, but the colors were still wrong. I got with Autodesk support, and after looking into it their "solution" was to open each part with the wrong color, change it to a different appearance, and then change it back.

Sorry Autodesk, but that's not a workflow problem, that's a straight up bug and something that should be fixed, not passed off as something I need to deal with because there's a tedious workaround.

This is they type of frustrating experience that I think both I an andrewdroth are experiencing.

[andrewdroth]

Yep,

I recently had a sketch that was fully constrained, yet one of the lines was being displayed as it's underconstrained color. I added a reference dimensioned and it switched to it's proper color. 

Bizarre, but not the end of the world. I took a screencast of the procedure and sent off the file so development could take a look.

The first response was somebody telling me that the dimension I was trying to create was not an option in IV. I told him to re-read the submission, as that was not what I was asking about.

The case was then passed on to another individual that told me the software was behaving normally and this is one of those cases were even though the sketch is fully constrained, it is not.

I just felt like I was being insulted.

Why i'm waisting time trying to help improve this software is beyond me.

[DRoam]

I'm casting a Kudo--not necessarily for the tiered expertise levels, but primarily to draw Autodesk's attention to the need to establish procedures for reps to follow when there is an overt bug in the software. Reps should be trained to acknowledge and report bugs AND suggest temporary workarounds if the customer desires. Not just the latter.

[andrewdroth]

To cement my concerns with the support team runarounds, I present the following screencast.

I've been told three times that the software is behaving normally, and that this is not a bug.

Trimming Arcs w/ Perp. Constraints