How does accountability work for Autodesk support?

[jsejcksn]

There are threads here where Autodesk representatives have confirmed an issue and then never respond again and the issue is never addressed in a software update.

Here is one example regarding the option to stop Screencast from automatically launching with Fusion.... It has been two years since the rep sent the improvement request to the Screencast team and nothing has happened.

Here is another example regarding the service status toggle being reversed. There has been no update on this in 3 months.

Please don't misunderstand—I'm not complaining about an imagined timeline not being met. As users, we don't have the ability to see the product improvement/feature backlog, so we can't see if things are being actively worked on or when they are slated to be changed (if ever). Rather, I'm voicing my observation about the lack of transparency into what appear like empty promises. It's very frustrating to be told "we're going to work on this" without any additional information, especially when the person saying it goes silent—and it is demotivating to report new issues or request enhancements.

Perhaps there's a way to offer users more insight into backlog items that correspond to reports/requests?

Any insight into the process from your side would be really helpful. 🙂 Thanks.

[brianrepp · Accepted solution]

Hi @jsejcksn - the short answer is that this is a sore spot for our systems.  When someone on the support team or development team formally capture an issue or request from the forums, it's added as an item into our backlog management tool.  Sometimes you will see Autodesk personnel post a reference number, but unfortunately, this isn't something that you are able to access and track (it's mostly for our own future reference).  Standard practice also calls for the backlog item to include the source (e.g. forums) along with a link to the specific thread where it was captured.  Once an item is marked as implemented by the developers, teams can and should update the forum thread giving notice of when the item is expected to be included in an update.  As I'm sure you have seen, this doesnt always happen - being a very manual process, it's prone to gaps.  In a perfectly functioning system, all of our customers would have access to issues they've submitted (irregardless of how they submitted it), and those issues would be directly tied to our backlog management tools, updating customers with progress or notice of completion.  I'm personally passionate about getting us there (and in fact have a meeting on the topic next week), but while simple on the surface, it's a significant undertaking that currently isn't scoped for F360.

Hope that gives some of the insight you were looking for?  On the two specific requests below, I've sent an email to the Screencast team to get a status update, and also checking-in with our UX team on the toggle button.

Cheers,

~Brian

[jsejcksn]

Yes, @brianrepp—that is exactly the kind of insight I was looking for—thanks. Will you be posting the responses that you get about those two specific requests here or will you post them in the respective threads?

[brianrepp]

I just responded to the one re: status indicator, but am waiting on feedback from the Screencast team.  The initial response I received is indicating that the behavior is as-expected, and although they have received this request previously, it's not currently scoped.  The reason being is Screencast establishes a direct pipe between the starting application and itself to pass the metadata, therefore starting Screencast with each associated application launch.  I'll report back when I have final confirmation on the priority status.

[brianrepp]

@jsejcksn - I wish I had better news, but I received confirmation that decoupling the launch of Screencast with related apps is not being planned.

[jsejcksn]

@brianrepp I appreciate your following up on this. Is there a way I can link or reference your response to the original thread?