Thanks for the follow up brconflict. I truly do appreciate it.
Regarding helping out, I don't personally manage anything regarding the beta team but we do of course recruit beta testers from time to time. If this is something you're personally and genuinely interested in, we do have an application form here:
http://www.cakewalk.com/beta/forms/ (now that I look at this form, we need to update it.. it's kinda ugly... I'll try to get that updated soon). Anyhow, that's a good way to get involved but obviously requires an NDA. You might not hear back unless we're recruiting though.
To elaborate on the systems in place for collecting feedback about the products stability, bugs, features, etc. there are
quite a few systems in place. Some automated, some not. These are a few of them:
The Fault Reporter system: The focus on this is stability. It's a bit different from the Problem Report/CWBRN form.
Built by a few members of our support team with help from our developers. Willy wrote a bit about this a while back. Willy's post:
http://blog.cakewalk.com/what-happens-when-you-send-a-problem-report-to-cakewalk/ .
Essentially the way this process works is if SONAR crashes, a .dmp file is sent to our servers. We have a home-brewed tool we created that analyzes the crash and logs cases directly with our developers by communicating with our internal bug tracking system. It provides us with a ton of data, both in terms of what our biggest crash offenders are, as well as a lot of information we can extract at the time of the crash should we need to investigate a certain section of code or third-party component.
For example, as of this exact moment the most reported crash issue coming in is something that we resolved with the X2a update. When I run the same report against X2a, there are no duplicates, indicating the issue was resolved. What does that tell us? That a LOT of people haven't even installed the update still to this day. I worked with a pretty big VIP artist today who was experiencing crashes and was under the impression he had X2a installed. He's a very smart and talented guy. Turns out he didn't have it installed. It's easy to make mistakes. He's probably been under the impression that "X2a isn't that stable" meanwhile the whole time he was on the release version which did have legitimate stability concerns that we patched right out of the gate.
Anyhow, this entire system is pretty automated, but it doesn't get ignored as a result of that. Making sense of the information does require real-time interaction as well... something I work with personally very often and our developers work on.
The Problem Reporter/CWBRN form: http://www.cakewalk.com/support/contact/problemreport.aspx The focus on this is if features are working as designed. It's a bit different from the fault reporter.
You already know about this, but to give you the back story about why it is even here. We have our
internal bug tracking system, but customers want a way of providing us with details sometimes. This form allows customers a means of logging a report and getting some type of official acknowledgement from Cakewalk of whether or not we're aware of the issue. A lot of the cases that come in are easily resolvable. In fact, the VAST majority are (over 80%). What this means is that often times people think they are experience bugs but we know we have a solution for the issue. That just goes to show there can be a confusing perception about things depending on your experience level and whether or not you've ever interacted with tech support before. Most commonly reported "bug" is audio dropouts, but 66.5% of people have not provided what audio device they're even using.
Often times when bugs do come in that are legit, we track down an internal report that might have come in from our QA team, our TS guys answering phones and emails, or our beta testers. Sometimes people log the same report multiple times, so data can get a bit skewed. If you ever see us return something as a "duplicate", this is why. We're trying to keep the numbers accurate and when we resolve a case, notify people properly.
Anyhow, the entire point of the form is really to notify people when we have fixes for issues. You provide us with your email address and the specific issue, we sync it up with our internal system, when our developers return a fix and the fix is released, we update the reports to notify you. It's nice to receive a report that an issue has been resolved with an update that's now available. This is, however, why there can seem to be huge periods of inactivity with the form, because we only update things when our internal reports are being migrated around and fixes become available to the public.
Tech Support & Customer Service: http://www.cakewalk.com/Support/contact/default.aspx Everyone working in TS and CS is in one way or another an extension of our Quality Assurance team (and theirs of ours). We have access to logging issues in the same manner so we'll forward things along and get them escalated by our QA leads who specialize in these issues. We're all pretty close here at Cakewalk, so it's very easy for me to hop down to someone and say "I just spoke with this guy on the phone about an issue he's experiencing, what do you think?". Noel could tell you I do this quite often.
On the topic of support, I can understand that sometimes things don't go well. Nobody (myself included) is perfect and we do get stumped sometimes. The important thing to identify is that none of us are working from scripts... only from our brains and the experiences we've had. Every single TS and CS person we have on staff is actually extremely qualified (degrees in audio production, engineers at local recording studios, live sound technicians, legitimate performing musicians, use all of our competitors products as well, etc.). I can't think of a single person on our support team that isn't insanely involved in many aspects of music creation, production and performance.
I think the important thing for getting off on the right foot with anyone in support is acknowledging the challenge of the job. Even with all of the experience in the world, it's not easy if not being given a chance from the get go. It's on us to handle these situations professionally though, so if we're not, tell me about. Send me a PM. I'll follow up.
The Feature Request Form: http://www.cakewalk.com/support/contact/featurerequest.aspx Pretty self explanatory, but definitely fill this out. Our Product Managers review it. It's a great place to express what you'd like to see.
The Beta Team: Yes, we do have a beta team and they do test our products. This is important because SONAR isn't locked down to a single OS or hardware configuration. The beta team gives us tons of solid feedback outside of the testing we do internally.
The Forum: I'm not going to leave this out.
Your opinions are important. We obviously do pop up and read the forums from time to time. We try to interact when we can, but even if we're silent occasionally we're not ignoring things. It is important for us to understand if people are actually happy with the features. Correct workflow, incorrect workflow, bugs aside... if a feature is working "as intended" but people are using it differently then we thought they might, then this type of feedback is important for us and we do pay attention. It's helpful for how we approach what's next.
What
isn't helpful, is requesting us to "fix things" with absolutely zero context. The last three recent threads I personally read on the topic of X2a/X2b were all started by members who have no history of internal cases with us and did not provide any indication of what is working or isn't working for them. It seems like border-line trolling. This isn't to say some people aren't expressing legitimate concerns, please don't mistake what I'm saying... but those people with constructive criticism are providing context right from the get go. I've seen a number of helpful users ask for clarification on some of these threads and to try helping, which is great (thank you!). Unfortunately their good intentions appear to be being drowned out in some cases.
...
These are just the systems I'm interacting with directly. I'm sure our marketing team could tell you a whole different set of data they get from surveys, social media, sales ($$$), etc.
I guess all I'm trying to express is that I'd much rather (personally) see people taking advantage of the systems above and interacting
with us versus
against us. The meetings I'll be in all week (including the two hour one I just came from) are ALL about things everyone is expressing they'd like to see as improvements made to SONAR. We collected that information from everything above.
All of these systems are helpful to us. I hope in return it can be helpful to you and other folks. It's important to communicate this I believe. Hopefully future announcements from Cakewalk will speak for themselves so I don't have to.