A short while back I participated in an internal event. A number of priority customers of our internal cloud service were invited for a feedback session, to voice their thoughts, listen to roadmap sessions and just to get to know each other.

There was one comment made there by one of the participants that has been on my mind since then, and it was something along the lines of:

"I have been using AWS longer than I have been using our internal cloud service – that is more than 5 years. Ever since I have started, I have only contacted AWS support once – when I managed to somehow corrupt my two-factor authentication token. I have never received a marketing call, never been invited to such a feedback forum. There has never been a need.

On the other hand, on our internal services, I am flagged as a priority customer, have weekly, bi-monthly, monthly feedback sessions, capacity planning sessions and escalation paths.”

This got me thinking, and I completely agree.

A service where I can say that I use and rely on is something that just plain and simply works.

Let me give you an example. How would you feel if you would have to have a direct line into your electricity company to escalate when your lights did not come on when you flicked the switch, when you had to meet with them to discuss how many appliances you were planning to use this month, if you were planning on baking cakes for a party this week, and therefore you would be needing more electrical resources this month – so the electrical company should be ready for your surge in power consumption. Is that a company that you would say you can trust?

Probably not.

You would like the lights to go on every time you flick the switch, and not have worry about leaving the air conditioner on the whole day because it is really hot that day. All I would need know is that I will pay more that day or month – because I use more of the service your offered.

When we try to build a service – we should be doing it in such a way that it is something that the customer should be able to rely upon, something that we should be able use – without having to have direct lines into the support team to ask questions, because that team has already provided the proper documentation to explain exactly what I need to know – in order to use that service. You have provided additional channels and ways for them to self support themselves. There will always be some who know more, and others that know less. There will even be times where your customers know a lot more and do things with your infrastructure that you would have never dreamed of doing on your own. Let them help others as well.

Provide them with the tools to share their knowledge with others, be it a Wiki that they can update, a chat room where they can also assist other customers. It will benefit your other customers for and will benefit you in the long run, because you will have less load on your support team to answer these questions.

Self service portals for as much as possible – exposing as many of your services as API’s so that your end customers can consume them – without having to ask you to do it for them. All of these and many more, are what makes a successful service, both a public one – and even more so one in-house.

Put in as much automation as possible – because scaling people is so much harder that scaling a process.

Not everything can be infinite – and not everyone can build a service at scale like AWS – but this should be your goal – even if it is not possible at day-1.

I will leave you with the wish that my colleague gave to our internal cloud service team.

"I hope we come to a time where we do not have to contact you – or have frequent meetings to discuss this service. We just consume the service.

When we get to that point – then you know that you are providing service that just plain and simply works, and you have done a really good job."

Some food for thought.

As always, please feel free to leave your thoughts, and comments below.