Page 1 of 1
Advice for reporting issues with Vars
Posted: Wed Nov 15, 2023 9:12 pm
by ryan-feeley
Hi everyone,
I've worked with three VARs over the years and have noticed a fairly consistent trend when I report bugs. The trend seems to be 1) assume I'm an idiot and must be mistaken; 2) assume I've never read the documentation, done any training, read any books, read every dang thing on the knowledge base, etc; 3) acknowledge something seems off with my file, ask about my setup, workflow for creating it, etc. Rarely does someone just read the initial email, reproduce the issue with the files I've provided, and then comment on their experience.
I honestly don't understand it. I've reported numerous bugs over the years to Optis, Ansys, SpaceClaim, Comsol, etc. Generally the support staff tries to be helpful, appreciates that my job isn't to discover bugs with their software, gets the issue forwarded on, and in a year or two or five it gets fixed. There's a general vibe of -- maybe humility? With Solidworks VARs it almost seems adversarial.
I'm curious if anyone has any insight or suggestions. Maybe someone who's been on the other side. Something just seems off. I don't know if it's overwork, IT systems that don't actually get the attached files in the hands of support staff, pressure from Dassault, or what. I don't hope to change it, I'm just hoping for a little insight so I can navigate it a bit better and adapt accordingly.
Solidworks has it's warts, and we ask it do a lot, but it seems a lot of functional issues slip through the cracks for no reason I can understand.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 2:56 am
by Frank_Oostendorp
The basic set-up of maintenance will have a lot to do with this. SolidWorks sells the customer a seat of the software, including subscription, to have acces to updates and full live support. The subscription fee is shared by SolidWorks and the VAR. In what ratio this sharing is done, is a big secret. Starts with 40% for the VAR, I have been told, but never seen any documents about this. So SolidWorks takes the most, and the VAR has to organise and deliver the support, do all kind of checks, and are only allowed to register major bugs to SolidWorks.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 6:50 am
by mp3-250
I just received a form for a pdm issue and my VAR wants all the info about our server even the setup(ram, cpu, windows and sql version) and detailed description of the workstation, the repeatability etc before even touching the issue itself because there is no info available in the KB. which is why I asked them in the first place , I have already searched the KB by myself.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 6:56 am
by mp3-250
Frank_Oostendorp wrote: ↑Thu Nov 16, 2023 2:56 am
The basic set-up of maintenance will have a lot to do with this. SolidWorks sells the customer a seat of the software, including subscription, to have acces to updates and full live support. The subscription fee is shared by SolidWorks and the VAR. In what ratio this sharing is done, is a big secret. Starts with 40% for the VAR, I have been told, but never seen any documents about this. So SolidWorks takes the most, and the VAR has to organise and deliver the support, do all kind of checks, and are only allowed to register major bugs to SolidWorks.
"major bugs" that we must back with proof of economic loss I may add...otherwise a simple SPR thrown at the bottom of the pLaTfOrM and opened forever with the problem untouched.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 7:37 am
by john@layketool.com
The one reason that the VAR is asking so many questions about systems is every one is set up different and has different hardware components that they will need to try to duplicate especially on random crashing. That would be like doing a test drive for buying a porsche in a yugo and saying it's not what I expected. I've had good luck with trouble shooting using the VAR we have and yes they asked all kinds of questions about our systems to try to set up as close as we had.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 8:43 am
by Frederick_Law
Fastest way to get it fix is join Beta test.
Test and reproduce the bug in current Beta, current version, old version.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 8:50 am
by DanPihlaja
Back when Fischer Unitech was still a thing, I raised a stink with them for assigning me a tech that didn't know anything about configurations. They handed me to a tech that was super new and when I told him that there was an issue with a configuration, I had to define it to him.
I finally asked him to hand me off to the next level up.
They finally did, and told them to please put a note into my file that I ALWAYS want to be sent to the next level up. Because I do my own troubleshooting.
They agreed with this and started doing that. It was a actually a good experience. Then Fischer Unitech got bought by CATI, and then CATI got bought out by Go-Engineer. I haven't called a VAR in about a year now....so I don't know how it will go.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 8:53 am
by Glenn Schroeder
From following this forum and the old official one for many years I've come to believe all VAR's are not equal. I've worked with GoEngineer and MLC Cad and been very pleased with the service from both (I wish our IT people here were half as helpful).
As far as I know @Alin is the only frequent contributor here who works for a VAR. Maybe he will have some insight.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 9:29 am
by AlexLachance
Try getting your VAR to appoint to you a specific technician that answers to all of your requests, this helps reduce the "Treat client as a number" factor.
I get decent support with my VAR, but it is troublesome and I had to do a fair share of bitching to get to the decent support.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 10:36 am
by TTevolve
Most of the time I usually ask here or look up issues on my own rather than creating a ticket with our VAR for most everything other than install issues. My experience anymore is that even for something easy they want system specs, copies of what you were working on and your first born child before they even talk to you, and then it takes most of at least a day to get back to you.
Back in the day, before before all the VAR merging (Like Dan said above) I had a direct email to a tech I knew at the VAR, little things were taken care of with just a quick email, those days are long gone. I used to always go to the "what's new" roll outs every year just to talk with the techs and get to know them personally and have a rapport with them, not anymore, I don't think there are any techs in my area anymore.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 11:35 am
by Arthur NY
As a former Tech support jockey for about 8 years I can tell you a lot that happens on the inside. Granted this was over 20 years ago so much has changed in many ways, all though sounds like much hasn't. Also there were around "50" VAR's back then across the whole US where as now there is about 5 and that's has only made things worse in so many ways. Bare with me while I try to lay this out in such a way that will hopefully make sense as to why support gets so bad....
Back when I started owners of VAR's would generally hire from a few specific categories of people.....
- Young designer/engineer right out of college with very little life experience. As you can imagine one of the main reasons was that their annual salary could be kept low. They might have used the software in school but they had to eventually go through same training classes that customers would. There wasn't any specific tech support training.... meaning you were shown the phone, how to log in to some CRM system to look the company's information (i.e. on annual maintenance or not as this would determine exactly how much help could be given.) And also how to begin to escalate things to Solidworks if necessary as they had their own tiers of tech support people.
- Background Specific Experienced People: So this generally would fall into a category of say someone who has a background in injection molding, Sheet Metal, electrical engineering.... etc. They would also, basically, be thrown into the deep end of the pool to start offering tech support.
In all instances every tech support person would eventually go to SW HQ and take a certification test which comprised of usually some written exam as well as some type of oral presentation where you did part of a demo in front of your fellow peers and Solidworks specific employees who would drop a hammer on your head if you screwed things up. All of this would eventually lead into what is now known as the CSWP exams, for which, a tech support person's passing score is actually higher than what users needed.
Generally tech support people would have triple duties.... tech support aka phones/emails, Solidworks user Training, and Solidworks demos to possible new prospects thinking about buying the software. On average this means a company is looking at around 3 - 5 years before a tech support person is even remotely competent to do the job. As you can imagine tech support is as much about customer service as it is about the knowledge of the product as well as critical thinking capabilities. It's in this last area that I would say that there is a direct correlation to each individual person which would only bare out over time or, at the vert least, trained into them by the tech support manager.
Even 20 years ago there was the famous 80/20 rule which is that you'd hear much more from a smaller group of users/companies than anything else. That 20% would easily take up 80% of a tech time. It would even get to the point where we, organically, would start to take on certain client's as "our own". Meaning if person "X" called/emailed in they would immediately get transferred to a specific tech because we were most familiar with the client/company. This way things would not be starting at 0 and for both sides was a much better experience. Very surprisingly this got some pushback from management for a whole host of reasons in the beginning. Eventually, after a few years, they realized that it was beneficial to have happy customers than irate ones that might walk to another VAR in the area (remember things were very competitive back then because of the amount of VAR options).
So when you add up all of the above you start to get a sense of what it means to be a SW tech support person. Here's the kicker.... the average life span of a tech support person is 5 years some might even do 10 years and the proportion of users to tech support people back then was easily 300:1 and the territory that the VAR covered was mainly just the north east. On the tech support team we had, roughly, 8 - 15 people all filling in those various roles of training, demos, and support. If you had to do the 4 day Solidworks training that lasted 9am-5pm that meant that any support cases being worked on pretty much had no progress happening unless another tech took over for you. (Hint: most techs don't like picking up a case in the middle of it.) Also the Solidworks tech support people were almost as bad, not all, as what you've described as your experience that you receive from your VAR. There were some that would try and be helpful and others that you'd cringed if you heard the person pick up the phone that day.
So this means you have an fluctuating level of tech support that could be all over the map in terms of understanding of the software (i.e. surfacing, sheet metal, toolbox, advanced assembly...etc), you have various levels of being someone who is service oriented and has the customer's interest at heart especially when you'd catch a tech support call that you knew nothing about and had to try and figure out on your own, through the knowledge base, or some help from a fellow tech.
I can't imagine what it's like today with the consolidation of all of the VARs. This means that tech to user ration is now maybe closer to 5000:1 and also that larger territories are being covered. I'm sure that Webex, Zoom, Teams meeting happen much more often today then back when I did it where trying to describe what's going wrong had to, mainly, verbally communicated. At one point the tech support group gathered the top 5 most repeated questions or issues which, back then, had generally a 90% repeat amount of way of resolving the issue. We wanted to make 5mins videos that would walk people through this and put it on our website (YouTube really didn't exist yet) and that way people could watch step by step how to resolve what they were seeing. This was shot down by management so quick that we didn't even have a chance to try and rebut how this was going to be helpful to all parties involved..... Le Sigh!!!
- If I was the engineering manager I'd demand that at least 3 tech support people be assigned to my company.... now this is going to hold a direct weight to the amount you're paying the VAR. One seat of Solidworks isn't going to go as far as a company with 20.
- In any call/emails to tech support I'd tell them from the start that you've already done the base things to try and trouble shoot the issue and that it needs to be escalated and taken serious. Just know that as a user you can look into SR/SPR's to see if this is an already known issue (which is not something you should have to do).
- Find out who the tech support managers are, get their contact info. The last thing they want is an irate client but you voicing to them, be it good or bad, an experience that you had with a tech support person goes a long way.
Hope this helps to give some insight into the life of a Solidworks tech support person at a VAR.
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 1:55 pm
by ryan-feeley
Thanks everyone!
There are some good nuggets in here that I can definitely apply. I'll summarize and add a few ideas of my own:
- Get the contact info to the tech support managers. If you're lucky, you can meet them in person during the annual "what's new" presentations
- You can get decent support, but it's not the default. You'll need to lay the groundwork:
- make it clear you do your own troubleshooting and get that entered into your file (whatever that file is, it sounds important)
- ask for a specific technician that answers to all of your requests
- there are "levels" to the support staff, some have CSWP-like creds, some do not. Try to get yourself defaulted to a "level-up"
- you may have to do a fair share of bitching to get the ball rolling
- the number of licenses you have definitely counts
- SolidWorks takes the most [of your subscription fee], and the VAR has to organise and deliver the support, do all kind of checks, and are only allowed to register major bugs to SolidWorks. I expect this explains a lot. The VARs just don't have the right incentives, and that is likely coming from Solidworks
- If the issues is bugs, wait for the annual Beta test program. That's how to get something fixed. If you or the VAR have identified a work-around, their job is done. Nothing is going to get escalated to Solidworks.
- They are going to want your computer setup info so just do an Rx problem capture from the get-go and include it.
[A FEW UPDATES TO THE SUMMARY BASED ON LATER POSTS]
Here are a few additions/modifications based on info from
@Tahhhd ,
@Peter De Vlieger, and others
- Maybe don't try to get a specific technician. That person may be on the road, and the VAR systems are optimized for the standard submission procedure
- More emphasis for "They are going to want your computer setup info so just do an Rx problem capture from the get-go"
- Clearly indicate the troubleshooting steps you've already taken.
- More confirmation that the VAR is likely going to stop as soon as a work-around is identified. So if you hope for a "fix" in the upstream, focus on participating in the Beta Testing.
- Rather than 50/50, the maintenance fee split might be more like 80 (Var) / 20 (Dassault).
Re: Advice for reporting issues with Vars
Posted: Thu Nov 16, 2023 2:18 pm
by DanPihlaja
ryan-feeley wrote: ↑Thu Nov 16, 2023 1:55 pm
Thanks everyone!
There are some good nuggets in here that I can definitely apply. I'll summarize and add a few ideas of my own:
- Get the contact info to the tech support managers. If you're lucky, you can meet them in person during the annual "what's new" presentations
- You can get decent support, but it's not the default. You'll need to lay the groundwork:
- make it clear you do your own troubleshooting and get that entered into your file (whatever that file is, it sounds important)
- ask for a specific technician that answers to all of your requests
- there are "levels" to the support staff, some have CSWP-like creds, some do not. Try to get yourself defaulted to a "level-up"
- you may have to do a fair share of bitching to get the ball rolling
- the number of licenses you have definitely counts
- SolidWorks takes the most [of your subscription fee], and the VAR has to organise and deliver the support, do all kind of checks, and are only allowed to register major bugs to SolidWorks. I expect this explains a lot. The VARs just don't have the right incentives, and that is likely coming from Solidworks
- If the issues is bugs, wait for the annual Beta test program. That's how to get something fixed. If you or the VAR have identified a work-around, their job is done. Nothing is going to get escalated to Solidworks.
- They are going to want your computer setup info so just do an Rx problem capture from the get-go and include it.
That is pretty much it. A lot of VAR's will tell you that more than just "major" bugs get escalated to Solidworks, but I haven't seen much evidence to prove that other than the "voting" system in the knowledge base....which as far as I know, doesn't do much for the first 5 years it sits there.
Re: Advice for reporting issues with Vars
Posted: Fri Nov 17, 2023 12:01 pm
by Arthur NY
The only thing that I'd adjust about your summary is....
SolidWorks takes the most [of your subscription fee], and the VAR has to organize and deliver the support, do all kind of checks, and are only allowed to register major bugs to SolidWorks. I expect this explains a lot. The VARs just don't have the right incentives, and that is likely coming from Solidworks.
I believe that this is closer to 80/20 in terms of revenue in fav of the VAR. It's one of the main reason why Private Equity is getting involved..... because the maintenance ratio is roughly around 80% - 90%.
Re: Advice for reporting issues with Vars
Posted: Sat Nov 18, 2023 6:43 pm
by mp3-250
The whole VAR (and also SPR and Enhancement) system is basically flawed and based of a large set of wrong incentives, at least for us (customers). SW basically found a way to neutralize user feedback , hide it from their management or or embellish it for PR/sales purposes.
Re: Advice for reporting issues with Vars
Posted: Tue Nov 21, 2023 4:24 pm
by Tahhhd
I left the VAR world about 13 years ago, and
@Arthur NY absolutely nailed it!
On the other side of the phone/email it was pretty easy to tell which customers had good/bad experiences on previous tech calls - which quickly evolved into them asking if specific people were available when they would call in.
(I ended up taking a few calls while at my new employer after a few of my 'regulars' found out that I had left and where I went - I don't recommend doing this, as it put me in a pretty awkward position with my new boss.)
Here's a funny tidbit of trivia for
@DanPihlaja - While I was at the VAR, we were very, very close to buying Fisher Unitech (FUN Tech) - It didn't happen, and about a year after I left CATI bought half of our locations (Alignex bought the others.) A few years ago GoEngineer bought Alignex, so if I had stayed on board (and made it through the exchanges) I would be working for GoEngineer today.
I still know several of the AE's from over the years, and I still occasionally submit issues.
This is what I do:
Prior to submitting the issue, I try to re-create it consistently, and will sometimes try it on a different computer.
Being able to re-create an issue makes it easy to capture it with the Rx tool. (If possible, ALWAYS send an Rx file - this gives them critical PC stats.)
Fully describe the process to reproduce the issue, AND list the things that you have attempted to resolve the issue.
(This is basically hitting the fast forward button on your case - "Yes, I've already re-booted!")
I know it is tempting, but try to avoid sending it directly to your favorite AE - Use the standard submission procedure, whether it be through their website or emailing
support@yourvar.com - This is usually linked to their CRM system for logging/assigning support calls - It will save your favorite AE the task of manually generating the support ticket. More importantly, this will get your issue in front of someone right away - when I was an AE, I was constantly on the road doing demos and/or teaching classes, which pulled me out of the support pool, and creates a delayed response for you.
Things have changed a lot since I left, but I do think that there are still people on the other side of the fence that truly want to help you succeed.
I have noticed a trend of hiring people fresh out of school with limited industry experience, which is a bummer, because being able to relate to the person in the field can make all the difference in the world.
Thanks for the flashback Arthur, it brought back a FLOOD of memories!
todd
Re: Advice for reporting issues with Vars
Posted: Tue Nov 21, 2023 7:41 pm
by SPerman
In summary, do all of the heavy lifting for the VAR/SW, and hope they actually do more than blow you off.
Re: Advice for reporting issues with Vars
Posted: Wed Nov 22, 2023 7:20 am
by Peter De Vlieger
SPerman wrote: ↑Tue Nov 21, 2023 7:41 pm
In summary, do all of the heavy lifting for the VAR/SW, and hope they actually do more than blow you off.
That's been my experience as well.
They are helpfull with general SW question such as ASM/PRT questions or Weldement questions or anything else that is core functionality etc..
But when it came to my speciality (piping) more often than not I had to explain my issue with hands, feet, Rx's, slabs of text, multiple phone calls before they would even acknowledge that it was indeed an issue let alone them actually trying to see if they could reproduce the issue on their end. I'm sure that each and every tech has far more superior knowledge about 99% areas of Solidworks compared to me but when it came down to piping it was a struggle to get heard. Getting an actual helpful resolving responds... *thumble weeds*
Getting them to try and do the steps that I described to see if they could reproduce... heck my wisdom teeth being pulled was easier and less painful.
The amount of times that I put in hours in getting the actual situation documented, recorded in Rx, described in step by step so that even a fool or a 3year old could follow, detaling all the things I tried and tested, what logic dictates could be the issue... only to get an email back that said the equivalent of :
- nuhhuh, no it works for us, while it was clear that they hadn't tested the issue at hand or even understood the problem
- did you reboot your computer (even when I clearly mentioned that even after a full reboot, reset, registery clean, safe mode, etc.. it was still doing it)
- send us your files, while already having done that and never hear from them again
Until after lots of nagging from my part I might get something that boils down to
- oh it's a known issue so it sucks to be you
- no worries, it's reported to be solved in alpha version of the one that is planned in 3 years time, which doesn't mean a thing because by the time it's 3 years later and SP0 is released it's broken AGAIN and I can spend another few hours to get them to face that it DOESN'T work and no the problem isn't with me, my computer, my settings, my windows but the <expletive deleted> product they sold us.
- use a workaround that comes down to not using the functionality at all for the next few years.
- or : nope, it's not an issue, Solidworks says that it isn't an issue so we have no clue why it doesn't work for you or any of your colleagues and there for case is closed
I mentioned it before, I play a game online that works not only on all kinds of PC's (with all kinds of types of windows) but also on Xbox (several generations) + playstation (several generations) + Nintendo + android + apple Ios and that with cross play and when anything half way serious goes wrong it's fixed within a week. It's a free to play game without pushing it's playerbase to spend money.
But this piece of so called
Pr
Ofessional
Software that costs thousands per seat per year whines about what type of PC you use (without being able to tell you what the actually working combo is) , what OS you use and expects it's user base to spend hours, days, weeks on trouble shooting their product that is put together with the equivalent of chewing gum and barbed wire and gaslights you when things don't work as advertised.
Re: Advice for reporting issues with Vars
Posted: Wed Nov 22, 2023 8:38 am
by mp3-250
@Peter De Vlieger let's add DS do not develop the kernel, the sketcher and many other components they license from third parties (and competitors like siemens). DS has a R&D full of engineers in India that is supposed to develop SW, but it seems they are not aware of the not so brillant performance of their CAD.
We have a lot of problems with drawings and this is the reason many still use 2D to avoid the pain of handling SW drafting, and I do not think we are alone with this kind of poor perfomance.
I used to draft more complex models with unigraphics 18 and a 32bit workstation with 2gb of RAM. If I had the 32Gb monster (with 12Gb VRAM) and SSD the model would fly out of the screen...SW freezes and almost choke with flat extrusion with holes.
unistalled and tried the same 3d with out of the box settings and SW drafting templates: same poor results, but nobody at DS ever noticed...
Re: Advice for reporting issues with Vars
Posted: Wed Nov 22, 2023 9:00 am
by DanPihlaja
Peter De Vlieger wrote: ↑Wed Nov 22, 2023 7:20 am
...
But this piece of so called
Pr
Ofessional
Software that costs thousands per seat per year whines about
what type of PC you use (without being able to tell you what the actually working combo is) , what OS you use and expects it's user base to spend hours, days, weeks on trouble shooting their product that is put together with the equivalent of chewing gum and barbed wire and gaslights you when things don't work as advertised.
This. This is my biggest frustration with Solidworks and the VAR's. They have NO IDEA....because if they do, they aren't sharing it with anyone.
Re: Advice for reporting issues with Vars
Posted: Wed Nov 22, 2023 9:50 am
by SPerman
I usually have found a workaround by the time I bother reporting it to the VAR. (Getting the job done is priority one.) IMO telling the VAR you have a workaround immediately closes the ticket, and nothing gets reported.