I have presided over IT escalations where one of the engineers on our team accidentally and completely destroyed ALL customer production data, rendering customer systems and our software useless. There is nothing more exciting than getting that phone call from the engineer at 5:15 PM on the way out the door to some significant event that my wife has been planning for months. What I have learned through these escalations, however, is that they are survivable, the customer will get back online, and they will still pay you support maintenance fees that year.
The following are lessons learned and principals I implement to successfully navigate these escalations.
Do not get emotional.
These types of escalations are extremely stressful. They don't have to be emotional. Emotions such as fear and panic will simply cloud any ability to identify root cause and draft a plan to resolution. I have walked into the middle of escalations in the past that have been a typhoon of scrambling engineers, yelling customers, and flustered managers. Half of a support and engineering organization has been pulled in to work on the escalation, but there is no clear understanding of the intended outcome of that work. When I get everyone to pause and take a deep breath, I always find that panic is the underlying motivator for the chaos.
The bottom line in software is that mistakes happen and data gets deleted. To think that this will never happen to any software vendor is completely unrealistic. I always start an escalation in full confidence that we will solve the problem and restore the customer to steady state. Confidence, not fear, is what underpins a successful escalation.
Be Sorry, but not Pathetic
Customers calm down significantly when I lead with a simple "I am sorry and I deeply regret the position we have put you in." To prevent customers of lesser professional integrity from kicking me when I am down, I immediately follow with "Getting you back up and running is my number one priority and my team is going to relentlessly work to fix this." I follow my humility with a statement of confidence to the customer, taking away any hint of fear or panic on my part. The moment I show fear or panic, is the moment the customer will pounce.
Create the Path to Resolution
Since my team messed up, I am responsible to the customer to provide both the plan and the fix. I never entertain a democratic conversation with a customer around a resolution. Not only will the customer question my ability to handle the problem, but I open myself and my team to unsustainable commitments suggested by the customer. Letting customers dictate the fix is a recipe for many late nights and "fire drills", making many employees unhappy on both sides.
Huddling the smartest people on my team, we come up with the most sustainable path to resolution that will ensure our success and the customer's success. We then come prepared to the customer meeting with a clearly articulated path to resolution. Hopefully, the customer will accept the plan as-is and we can get on to fixing the problem. If the customer pushes back, I listen to their objections, but always offline a response, never committing to anything in real time that is outside of the plan. If the customer objections can be mitigated and are reasonable, then I incorporate them and propose a revised plan. If they are unreasonable, then we have to push back or come up with an alternative. There are times when we simply can't accommodate the customer objections and we have to move forward with the path to resolution suggested. I never put my team in a position of failure while trying to clean up a failure.
Relentlessly Overcommunicate
Once we all agree on a resolution, I setup at least 2 phone checkpoints, one in the morning and one in the afternoon with the key customer stakeholders. I then direct all communications to be addressed in these meetings. I politely ask all parties to refrain from side email and phone conversations, saving all topics for the checkpoints. I instruct my employees to only respond to emails or calls if they are a tactical request that will further the agreed upon path to resolution. Any communication that suggests any deviation from the path is folded into the phone calls.This principal squashes all risks that the escalation will be sabotaged on purpose or by accident through muddied communications.
As the leader of the escalation, I send no less than 2 - 3 additional emails to the key customer stakeholder, letting him or her know our status throughout the day. Sometimes these emails state that we have nothing to report. My goal is to prevent the customer from ever feeling that they are losing control or lacking status.
By applying these principals, I have been able to methodically work through an escalation and restore a customer to steady state. In most cases, the customer ends up thanking my team for the professionalism and communication through the process. My team may have pulled a few late nights, but they went to sleep confident and I was able to enjoy my night with my wife, doing whatever she planned for us to do many months ago.
No comments:
Post a Comment