Sure, all customers want their requests completed, but you can't always get what you want, and everyone knows it. However, if people don't feel acknowledged, they won't be happy. At worst they will feel ignored; at best they will assume you aren't doing something when you are.
Don't customers want everything right now? No. I believe that customers know, deep down, that they can't always get that. If they ask you to order a new PC, they expect the request to be acknowledged, but they know that even with overnight shipping, they're not going to be able to stand in your office waiting for it to arrive. They will be satisfied with an acknowledgment and a date on which they can expect the order to arrive.
Customers Want to See Action More Than They Want to Receive Action
Once I was in my office and a customer rushed in.
"Server XYZ is down!" he said, in a panic.
"I'm on it!" I replied.
I turned to my workstation, typing occasionally. From what the customer could see, it seemed like I had simply returned to my work and was completely ignoring his panicked request.
This was in the early days of remote serial console or long-haul KVM switches. I was actually hard at work fixing the problem, but visually the customer wasn't seeing me do anything different than when he arrived.
He became upset. The customer's expectation for "fixing a down server" involved me jumping up, running down the hall, fiddling with the funny combination lock on the machine room, then laying hands on the server. Because I wasn't meeting his expectations, he expressed his dissatisfaction in rather colorful language. He thought I was just going to sit there and do nothing to see if the server came up on its own. I was able to clear up the confusion by showing him what was on my screen.
When this happens now, I assume that the customer does not know about console servers and long-haul KVM switches. First, I verify that the server is down while I announce what test I'm doing. "Let's try pinging it!" I announce. "I can't reach it." But then instead of dashing off to the data center, I say something like, "Hey, have you seen this? I can access the console remotely as if I'm in the computer room!" I turn the monitor so the customer can see what I'm doing, show off the technology a little, and then go to work fixing the problem.
Soon they get bored and go away, satisfied that I'm working on the problem.
My little demo slows me down a bit, but it is still faster than actually walking to the computer room, and the customer is much more satisfied because she receives visual proof that I'm attending to his request.
"Bored but satisfied" is so much better than "panicked and impatiently waiting."
Conversely, customers will be the least satisfied if they feel ignored. This has nothing to do with whether they really are being ignored. If you start working on their request but they don't know you have, they will assume you haven't. That sucks, but it's true.
Hopefully I've convinced you that acknowledgment is important, and managing your time based on your priorities is important. So how do we combine the two? By using the process of delegate, record, or do.
That leads us to the next section.
Delegate, Record, or Do
When someone interrupts you with a request during your designated project time, you have a few options:
Delegate it. If someone else can do it, delegate it to him.
Record it. If only you can do the request, but it isn't urgent, record the request. Be sure to do so in a way that the customer trusts; don't just promise to remember it.
Do it. If the request is truly urgent, such as a service outage, drop what you are working on and do the request.
I admit that I actually pause to think, "Delegate, record, or do." It helps me focus on what I'm going to do with this person who is, alas, breaking my focus. The following sections provide more detail about this process.
Delegate it
If you have set up a mutual interruption shield as discussed in the opening of Chapter 1, you can refer the person to your shield partner. You don't have to say, "I'm sorry, but this is my project time, so I'm going to shove you on someone else." You can say it very politely.
Since people need a visual, positive confirmation that they've been heard and taken seriously, I think the best technique is to pick up the phone and call your shield partner to delegate the request while the customer watches. People don't want to have to re-explain themselves to each person they get delegated to, so I always try to explain the issue to the delegate. I can often explain it in technical terms, which is more efficient than the customer's original request.
Here's the general form: I say out loud, "Ah, let me ask Mary to do this" (I pick up the phone and dial Mary). "Hi, Mary. Joe is here. He needs X and Y. I'm sending him over to you." I look at the customer and say, "Stop by Mary's office, and she'll help you." Now Joe has received excellent acknowledgement of his request, and Mary is prepared to handle the task.
Tip
As technically inclined people, we often forget what it's like to be a nontechnical customer making a request. It may have been difficult, and possibly scary, to figure out how to phrase the request, so taking the time to explain it to Mary in your language makes it easier for Joe.
Sometimes the request is rather complicated, and I don't want to risk the miscommunication I can introduce by repeating a request incorrectly. However, I can still help focus the issue. For example, "Hi, Mary. Joe is here. He has a rather complicated request related to the web server. I'm going to send him over to you right now."
Of course, there are times when you are in a hurry and just can't call Mary. I think it is obnoxious to answer a request with a question like, "Did you talk with Mary?" A better way to express this is to simply say, "Mary is on call right now. Could you speak to her about this?" It sounds more official and orderly. People find a certain comfort to following an official process.