Wednesday, July 2, 2008

Today's Gripe: Drive by Tickets OR How can I give good service if you won't let me

I have a pet peeve that I call drive by tickets. I define them as a ticket or request that someone makes at the last moment before they become unavailable to talk about the ticket or request that they made.

My first reaction to a problem ticket or request is to communicate with the requester. Regardless of how much detail they put in the ticket I want to make sure that I get the full story before I work on it, especially if I need to make a change. I think that it is only responsible to make sure that I am on the same page with the requester before I service their request. I can't think of a time where following up with a requester has not provided value. To me, it's what providing service is about.

When people make a request and then go off to an all day meeting, go off-site for a seminar, or go on an extended vacation; my ability to service their request is reduced. I can only go on the information that they give me. Sometimes I have enough information to service their request, but usually there are some details that could help better service the request that are not communicated within the request.

When I need to take action to service a request without communicating with the requester based only on the information provided in their request, there is a greater chance that corrective action will need to be taken to correct the gap between the intent of the request and the product of the actions taken to service the request. At this point, the requester and I are probably having a meeting that contains our coming together to better understand the needs of the requester, but we're probably also going to discuss other things, like why did I screw it up.

This type of change is more expensive than it might appear.
Any support people who helped me service the original request probably will need to help me service the corrective request also. That is time that could be spent performing other tasks, like supporting changes that won't need to be corrected for other people.

Let's consider an alternative: I meet with the requester and understand their needs and communicate with them about how I can meet their needs. I learn more about what I can do, maybe I can influence their outlook. Maybe I can provide something that is more simple or that exceeds their original expectation. The net result is that the requester will probably be happy about the attention that their request receives. They will also be happier that their request is taken seriously. When their request is serviced they will be delighted by the experience.

Compare that experience with how the requester must feel when they make a request and the action doesn't exactly meet their needs. Their mood will not improve, instead it will deteriorate until the meeting with the managers is called where the requester discusses why their request was not satisfied. It's not going to be a very happy meeting. It should be the lowest emotional point for the stake holders. The actions taken from that point are more likely to actually satisfy the request and will likely improve the mood of the stakeholders. However the stress of the initial disappointment will spoil some of that joy.

I'm not a fan of having meetings for the sake of meetings, but something meetings actually can do good things.

No comments: