The Good Luck Call

I enjoy calling into contact centres – not because I do it for fun – but because I’m always interested in how they are going to solve today’s problem.

Think about it – it’s you, another person you’ve never met and a phone.

But I can tell you the one line that runs shivers down my spine – whether it’s been a good call or a bad one is when the other person on the phone utters those fateful words.

“Good luck”.

You’d think it’d be a great feeling, but it’s not.  We could have this great troubleshooting discussion that I think is actually going somewhere and then they utter those two words that seal my fate –

“Good luck, from here on in, you’re on your own, I hope you packed your bag because this is a doozy of a problem”.

That is quite honestly how it feels when I hear those two words.

What I want to hear, and I suspect most want to hear as well – “Try this, not sure if it will work, but I’ll check back in on you in a day to see how it’s going.”

Now I’m not alone trying to figure this out, now I have a co-pilot.

When Customer Service goes Boink

When you need to wait three days to talk to someone on the phone, for two minutes to solve your problem.

When the team you need to speak to, does not give out their number because there are too many calls to handle.

When the timer expires for how long you have been in the queue and drops you.

When the automated chatbot or IVR don’t actually help resolve your problem but instead motivate you into finding a way to try and game the system.

When the agent asks for the information that you only just provided the automated system with 30 seconds go.

Customer Service is the most powerful entity in any organization today, determining the success of any product and/or service based on that customer engagement.  I have taken to calling into an organization’s service centre before I buy a product to see how I will be treated outside of the sales relationship to ensure it will mimic what is being sold.

Everyone is happy when there are no problems, but keeping customers happy and assured, when things go wrong is a skill unto itself.

Customer Service in an Era of Automation

When everyone is talking about the ubiquity and general awesomeness associated with chatbots that can handle base customer interactions.

Are we talking about the benefits of increasing customer loyalty and satisfaction or are we talking about the increased benefits in reduced, qualified agents to help customers solve their problems?

Will the chatbot be the differentiator in customer retention or the next cool thing that lets the customer *think* they are talking to someone?

Like anything, it’s understanding what Service problem we are trying to solve and whether it is really for Customer.

Do you work for the Cycle or for the Customer?

There is a big difference.

If you work for the Cycle – billing cycles are incredibly important, who does what, when, how – what estimates are provided, how did you measure up, etc. Is perpetual new client business your goal? Are leads measured by their quantity or quality?

Predictability is the key metric for growth and delivery.

If you work for the Customer – how did they receive the project, what was their overall sentiment before billed, what was the end result for the company is what matters. Is repeat business the only measurement? Where does your success come from? Are you prepared to wait for the perfect customer?

You can do both, of course, you can, but you will always do one more than the other and that is paramount in establishing to you, your customers and your team where you stand and what matters most.

Neither is the big baddy but you cannot be one to one customer and one to the other customer – that breaks your focus and muddles your vision of where you want to be and go.

It’s not the customer’s job to make this call, it’s yours and it’s your job to make it before you get the customer.

The PD Day

I loved these as a kid – PD Days – the extra day that would pop up here or there on your calendar, sometimes at the last minute giving you a whole extra day to sleep in, play lego, goof off, whatever.

For those in Education – they stand for Professional Development Days – from Google.

PD days in the school calendar recognized that teachers needed time during the school year to hone their skills, improve practice, and stay current with changes related to teaching and learning.

I don’t see this much in software, you hear about, sometimes it takes shape for a period of time, but then we get busy with the next release.  Or some people take it, but others don’t, or you are sitting there thinking you should really be helping on that release and you don’t get to really apply any focus.

And then there is the inevitable piece that it must be tied to what you are working on – aaack.

But what if PD days for Developers were something completely different that emboldened the same criteria in the definition of the above;

  • Hone your skills
  • Improve with practice
  • Stay current on changes in the industry
  • Experiment
  • Create
  • Learn
  • Share

That last one is key and one I would add to the above definition, share what you learn, share what you succeeded at, share where you failed and think about what you are going to do on your next PD Day.