Are vendors cheating on tech support?

[kiddpete]

When I bought my Alienware, I purchased three years of 24X7 tech support, but when I call later in the evening I get a message about the office being open from 8(?) to 6(?) Pacific Time. When I do get through, the help is usually ineffective consisting of uninstall/reinstall which chews up lots of time, but doesn't solve the problem.

Ditto for other vendors who don't understand their own technology, have trouble speaking English (India?), or sound like trainees.

http://story.news.yahoo.com/news?tm...ashpost/20031222/tc_washpost/a17047_2003dec20

 

[PcAbuser]

Strongm,

In all fairness, Microsoft is a multi billion dollar company. The company I work for is a subsidiary of a large company, but has it's own set of books, and is serperate from the mother company.

Companies such as MS can maybe afford to have thier engineering group spend time on customer support, with hundreds in thier engineering department.

But the company I work for, has less than 10. The smaller ones could ill afford to have their enigineering staff doing the job of another department, else they can fix bugs, enhance existing products, or make new ones.



Do well unto others, else you will/should, not respect what you see in the mirror at the end of the day!

 

[TheVampire]

Look at my case of working at the same company for 13 years. I started in production for a few months, then moved to technical support ( phone and onsite ) for a few years, then did project management / sales for a few years, and now I work in engineering. Mixed in with this I also wrote tech documents and manuals, and did several hundred CAD drawings.

This gives me the experience of seeing how the various departments work, and what is expected. Now I can use this to reduce the load on the technical support, and give the sales people the products they need to satisfy the customers. And if the tech support people have a particulary hard case they come to me and I give them direction on how to solve it, verses them just transferring the call to me. This gets the customer fixed up, and the tech learns something ( I hope... ) along the way.

Granted, this may not be possible for everyone, but it works for me!

As a smallish company ( 50 people ) we cannot give 24 hour support, but we do have extended hours til 8PM EST so that people on the west coast can reach someone up til 5PM Pacific time.

I once told my boss that the technical phone support manager should not be taking calls, but should be aiding the junior techs in their calls. If it's so busy that the manager has to take calls, then it's time to get another tech.

Robert

 

[strongm]

PcAbuser, I think maybe you are missing my point

 

[Georgi1chuikov]

strongm
If I am getting you right... I do aggree that designers should code with the ultimate goal of end user ease of use, However, personnaly being in all levels of the tech support chain I have seen that the needed skill set of the engineer as opposed to the support personal is pretty different. Many (not all)of the designers I have dealt with really do not have the wide array of knowledge needed to identify what issue they are dealing with when they get that tech support call like: general OS and hardware issues, PC abuse issues like malware, bad uninstall/installation routines of other softwares that mess up shared files, etc. A designer is usually hired to create said product to work in the given test environments within the given specifications. A support guy is hired to keep it working in the a real world environment that has to deal with mutitudes of unheard of issues that can step on your product. Kidpete showed this with his second post. The issue did not have anything to do with the actuall software he was telling his support guy to help him fix. Conversly, The support guy should have been able to type in the word "echo" on his call tracker to see if he has encountered this issue in the past and what was done to fix it so this support issue problem could be a lack of good tech support documentation.

 

[PcAbuser]

strongm,

I did not miss your point, but as Georgi1chuikov said, the jobs are different.

In many places, the engineering staff is working as a team, each cutting their own piece of the puzzle.

I was merely looking at this from an economic view.

Keep the coders, coding.
Customer support is for the people the company hires for that job.

The number one concern in a company IS customer support, but i DO agree at some point engineering does need to get involved.

I disagree however, that they need to spend time on the phones.

Sometimes, engineering doesn't even fully understand what role the program plays in the grand scheme of things within the customers business.

This creates a situation where engineering doesn't under stand the workflow of the customers production/usage.

I think that engineering would be better off spending time onsite at a customer's place of business, and seeing first hand how their products are being implemented.

This in MHO would provide MUCH more insight into how to make the product better before it leaves engineering, thus making a more stable product for the consumer.

If a program is tested thoroughly by enigneering, then backup testing done from Tech support for engineering (or customer service which happens to be engineerings tech testing support in the case of my company), the product "should" be fairly ready for the market.

This is not to say there won't be bugs that need fixing, but will help in reducing them.

The reason our service department does final tesiting, is because we are the ones who actually use the apps, install and support them, therefore being able to produce more real life scenarios for potential bugs to present themselves.



Best Regards,

Marlon

My personal credo:
Do well unto others, else you will, or at least should, not respect what you see in the mirror at the end of the day!

 

[strongm]

>I did not miss your point

>I disagree however, that they need to spend time on the phones

Well...yes, you did, and are continuing to do so. I wasn't saying that engineers should spend time on the phone. I was saying that the engineers could limit (although not eliminate; this is the real world) their exposure to support calls by better engineering their products in the first place.

I mentioned the Microsoft experiment as an example of a company that was trying to encourage this idea in their engineers. By deliberately exposing them to first and second line support calls the idea was that the engineers would write better applications that required less support (to which the engineers allegedly responded by producing the Office Assistant)... I was not by any means suggesting that companies should put their engineers on the support desk as a matter of course

 

[PcAbuser]

strongm,

Again, I did not miss your point. You are right about the engineering staff benefiting from exposure to the end user, I just happen to disagree that it needs to be done by phone.

I did however offer an alternative, that has had HUGE benefits to the products they put out, and that is to spend a few days at the customer site, seeing thier work in action.

I realize this would not be the best option for all types of software companies, but to the customers our company serves, and the products they make, gets FAR better results.

In my opinion, the customer is BEST served my having the service personell go to the engineer with the problem, thus learning someting his/her self for future calls.

This is and of itself will take burden off of the engineering department, (leaving tehm time to CODE) and also makes them aware of any problems, so they too learn a few things for their future products.

How about we agree to disagree, since we both appear to be approaching this from a different angle?

Best Regards,

Marlon

My personal credo:
Do well unto others, else you will, or at least should, not respect what you see in the mirror at the end of the day!