Five Tenets of Project Customer Service

The trip my wife Elizabeth Larson and I took to South Africa to speak at this year’s BASSA 2013 ended well. The conference had over 200 registered participants, and the organizers kept the sessions moving smoothly. We were delighted with the response from the attendees, made new friends, and re-connected with existing ones.

While travelling a bit in the country, several customer service interactions stuck out to us and got me thinking. What would be your top tenets of “project customer service?” Here are five that come to mind after returning from our trip.

1. Promise enough, and deliver on what you promise. Forget the adage about “under promise and over-deliver.” Quite often that approach leads to scope creep since we are guessing about what “over-delivery” means. . One hotel we stayed at surprised us with coffee and tea delivered each morning to our room. This was a pleasant surprise, but I think it would have been better if they advertised this feature (to help us justify the high cost of the room!).

If we consistently under-promise and over-deliver, then stakeholders will soon “get wise” to us and not trust our estimates. My colleague Andrea Brockmeier posted an excellent blog recently on this same topic.

Instead, we should “promise enough and deliver what we promise.” It means making commitments and keeping them, a huge factor in building trust. It means making accurate and honest estimates for project work (and yes, I understand the trap of being held to an estimate). It also means being realistic and firm about what we can accomplish in a given timeframe, even if we’re pressured by a sponsor to hurry up.  That can take courage.

2. Keep the customer informed. One hotel we stayed at had a specific process for handling a guest with two reservations for one stay, which might occur when a guest wants to use two different forms of payment for the stay. In our case IIBA paid for the nights of the conference and we paid for two additional nights. Imagine our surprise when our keys suddenly stopped working! We had no idea the hotel would deactivate our keys when the first reservation ended. It was a minor inconvenience, but would not have been any inconvenience had we known to get new keys for the personal part of the stay. The check-in clerk knew we had two reservations, but failed to notify us that our keys would need to be re-programmed for the 2^nd half of our stay.

3. Keep things personal. A different hotel we stayed at had superb customer service. They used our names everywhere from check-in at the restaurant to delivering a package to our room. They knew when it was the first time we visited their restaurant for breakfast so they could explain more details to us. It was a simple but highly effective way to make us feel wanted and valued as “stakeholders.” How often do we personalize our project stakeholders’ experience? Are our projects impersonal and mechanized dealings or do they contain some “high touch” activities like the hotel example?

4. Have formal processes for when things go wrong. I thought I had lost a camera at the high-touch hotel. When I reported it, their reaction was extraordinary. They treated it as an “incident” and went to great lengths to help, including reviewing their video surveillance tapes and having the on-duty manager personally speak to us. They even delivered an incident form to our room for me to fill out.

Their response was organized and efficient, making me feel like their “non-happy path” process was well-thought out. For our work as BAs and PMs, do we have good processes we can follow when things go wrong? For example, how are our change control or risk response processes?

Parenthetically, we found the camera in a colleague’s car and I was happy to update the incident report. All’s well that ends well as the saying goes.

5. Be flexible when we can. Our flight out of Cape Town was not until 11:30 p.m., so we wanted as late a check-out time as possible. The hotel had a standard time of 11 a.m., which was a bit early. We asked for a later time, and got one, although a manager had to approve it because it affected an incoming guest (another refined alternate path process, maybe?). Instead of just saying “no” to us, as many hotels do, this hotel was flexible and gave us a little more time. It wasn’t as late as we’d have liked, but it helped. On projects we always have limits and constraints like a check-out time. But, are our processes too rigid and get in the way of providing good service to our stakeholders? At Watermark Learning, we preach the concept of “structured flexibility.” In short, this concept means we need strong, consistent processes that get consistent outputs. We also need to allow people the flexibility to adapt them to meet the needs of a particular project or stakeholder.

My list may is by no means complete. What other tenets can you think of?