January 6, 2010 at 8:46 pm
Comments posted to this topic are about the item Being Supportive
January 7, 2010 at 1:41 am
I fully agree with you Steve. If you're the one that took ownership, and got the problem fixed without the user having to get involved, they remember that, and you'll always get repeat business and referred business from that person. (Seen from a one-man/small business perspective)
January 7, 2010 at 5:27 am
A problem is if you accept to many issues that is not yours to solve, you are not doing what the company is paying you to do. If you do help someone who instead of following protocol and report the none critical issue and waits, decides to go directly to you for help and you help them, they will remember that and again come directly to you and possibly hinder you from doing the task you are currently working on etc. Thus maybe the approach to this dilemma is a little more complex and should be thought throu.
January 7, 2010 at 6:53 am
Sometimes it seems that IT is its own worst customer. From what I have seen, we do a good job working directly with our "End User" (or customer), but if that customer is IT staff then for some reason, the support sometimes falls short, thus the real Customer suffers.
January 7, 2010 at 7:21 am
In the world of Metrics, Metrics, Metrics, SOX and HIPAA, it is often the process that is to blame. Management, particularly upper management are well aware of compliance requirements but the end user??, not so much. They miss the day where they could call IT and the problem was solved ASAP.
While we take ownership, we have no control over the bureaucracy nor the user perception of why does it take SOOOO long to reset my password.......
M
January 7, 2010 at 7:42 am
A customer will remember that you walked them through getting the problem resolved (especially if it was not your group that needed to fix the issue) versus you just telling them they need to go talk to "so-and-so".
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
January 7, 2010 at 8:25 am
I completely agree Steve, the business doesn't care if it's a router, or network, or bad application code, only that it's not working as it's supposed to. When a problem comes in, then even if it's not yours to solve, make sure it gets routed to the right group who can solve it, rather than directing the customer to call that group, and don't ever blame the problem on another group, just get it fixed, makes for a happier customer, and a better IT team, now if we can just get those darn application guys to quit blaming the database for the issues! 😀
January 7, 2010 at 8:51 am
OK stand by for the rant here.
One of the best things that happened at the dental company was that the development team worked for the support manager. It did not take long to figure out that a software company was not going to change how dentistry was practiced. New innovations came from our study of how software could help the dental staff (doctors included) to their job better or faster.
We use a lot of analogies when talking about what we do in software. We use constuction and remodeling to describe project management. I use healthcare when talking about support. "Doctor, I have a bad pain and can barely walk." "Well, come in and let's take a look at you." "I can't do that! I'm too busy. Just fix the problem and call me when I'm better." :w00t:
We get the few word problem description and then get challenged to solve it fast. Customer XYZ reports that they can't receive product using our system. In the daily meeting i get asked for probable causes and plans for solution. I look at the team and wonder what they were smoking for breakfast. Huh? Turns out there was a power cut on the loading dock and the wireless devices could not connect to the network. The software was fine.
"I need to ship these pallets that are on QA hold and the system won't let me. What's wrong?" Well no shirt! The system is designed to prevent you from shipping food that might be tainted or expired.
"I moved these pallets because the racks are being painted but the system still thinks that there is inventory on those racks." "Did you scan the pallets as you moved them and record the new location?' "Well no." Sometimes you just want to hang up on people like that.
ATBCharles Kincaid
January 7, 2010 at 8:53 am
Agreed with Steve about avoiding the blaming game and being supportive of each other regardless of where the issue comes from. But I have to also agree with IceDread concerning people coming directly to you when you are known to resolve issues quicker, often because someone is more familiar with business logic or the bigger picture. Users having the issue tend to bypass the authority channel, which is fully understandable in small companies but sometimes get in the way of getting your real work done. In that scenario, cross training and taking the time to explain is key to being supportive by spreading the knowledge.
"Any fool can write code that a computer can understand. Good programmers write
code that humans can understand." -Martin Fowler et al, Refactoring: Improving the Design of Existing Code, 1999
January 7, 2010 at 9:09 am
I'd agree w/ Icedread that this can be a double edged sword. Without a doubt if you help someone they'll come back to you. that's good and bad. You're building relationships, which are what business is about. It's not a cold, impersonal set of transactions, regardless of what you think. It's people bonding and working together, customer and vendor.
If someone feels comfortable to you, I think to a point (you have to set this), help them again. Point them to the right person, or introduce them. Get them help. You don't have to solve the issues, but you can help out.
January 7, 2010 at 9:41 am
If the network does not work, your application is broken.
If the server is down your application is broken.
If the server is slow your application is slow.
If security has a user locked out, your application is not working.
If whatever is not working your application is not working.
Our job is to get the application working. So we fix what is wrong and move on. We blame no one for that does nothing for the user and denigrates others in IT. Focus on problem not on blame and fix the application.
The user does not care about anything except they can not use the application. Do not burden them with extra flap, just fix the application and all will be happy. A running application makes for a happy user, happy boss, and happy developer, so make the application run. 🙂
Not all gray hairs are Dinosaurs!
January 7, 2010 at 10:28 am
I've made the mistake of helping a few people directly with their Word/Excel/Outlook problems rather than telling them they need to wait until our tech support team can get back to them. Now word has gotten out to call me first for those types of problems leading to my phone ringing all day long.
Those database projects I'm supposed to be working on that are necessary for regulatory reporting....not getting done.
January 7, 2010 at 12:01 pm
I think this is something that needs to be done judiciously.
When I read the article I immediately thought of finger-pointing and back-biting putting the blame on this department or that department. That kind of behavior is destructive to the IT team.
Reading the posts, I see the flip side. If you are super nice and drop everything to help User X, you may be sabotaging your own projects and work.
If the IT is functioning as a team, then when an errant request lands on the DBA desk for help with Excel it could be quite easy to redirect the request without finger-pointing and without the end-user feeling dismissed. A simple "let me check with so and so" or a "i think i know who can help" or "i will look into it" can go a long way for the requester in many cases.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 7, 2010 at 6:57 pm
Also educating the customer on what the problem was and the fix required to solve the problem is also paramount. For example, the database server is stopped and the customer is using the application to connect to the database server. An error message is displayed to the customer about some sort of connection problem. Showing the customer how to start it up when that kind of message appears will help educate the customer. Therefore you won't get repeat calls from the same customer for the same issue.
January 8, 2010 at 9:41 am
Not sure I'd want the end user starting up a database server on their own.
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply