A colleague of mine had been working with a difficult customer for some time. He was making good progress with the customer and their issues. Late on a Thursday he sent me a request for support with a customer deliverable for the following Monday morning at 7:00 AM. This request would require essentially a one business day turnaround, or the team to work over the weekend.

 
Now sometimes a customer request should and does require the weekend work. After a little discussion with my friend it was determined that his request was a “nice to have” not a “have to have” capability for the customer. I then asked why we wanted a “nice to have” deliverable in a “have to have” time frame. He responded by saying he was trying to show our responsiveness to the customer.

 
I explained that my concerns were multiple: I didn’t know if we could scope the work (estimate the time effort and complexity of the request), and implement properly it within the time frames he was trying to set. I also told him I thought that there was a significant risk that our demonstration of responsiveness could backfire on him. He asked how.

 
Customer satisfaction is based (in my opinion) on economic expectation theory. Simply stated that means if you set your customer’s expectations at a specific level, and then meet those expectations, your customer will be satisfied with your performance. In this instance I pointed out that if he set the customers expectations for receiving this incremental functionality (nice to have) in an achievable time frame, and we in fact were not able to deliver it in the desired interval, we would not have met the customers expectations. This would have turned a potential opportunity to build customer trust and relationship into a negative experience for the customer.

 
It would not have mattered that we were trying to do something for the customer that might have been above and beyond the requirements of the contract. What would have mattered is that we would have committed to providing something to the customer within a certain time frame and then not delivered on it. The point here was that when you commit to providing something, even something you are not contractually required to provide, it becomes an expected deliverable and is viewed as such by the customer.

 
What we instead did in this instance was commit to providing the desired incremental functionality for the Monday a week later than my friend wanted. This provided us with the time required to properly scope and perform the desired tasks. We ended up providing it on the Thursday of the week that my friend wanted (not the Monday) and were able to be perceived by the customer as both providing incremental functionality and providing it ahead of our commitment – a two for one on the customer satisfaction score card. More over we were able to set a reasonable expectation by the customer and then meet it.