customers think the vendor cares while they actually discard the submissions. I don't expect to receive a phone call from a product manager saying, 'Hey, remember that crash you had last week? Thanks for submitting the report! We've fixed it and named you Customer of the Month!' However, it would be nice to receive email to acknowledge the submission. (I should note that when Tom Reingold was at Bell Labs, he not only called and congratulated the submitter of every 1,000th request, he took them to lunch and used it as an opportunity to ask them how they would like to see service improved. So there!)
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
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.
