James Watson's Blog (Support Manager)

One of most important aspects of delivering a fantastic support service is always ensuring that you do what you say you’re going to do and when you say you’re going to do it. Our customers rely on the service that we offer to keep their operation running smoothly; if we commit to something and fail to deliver we are letting that customer down. This might have significant consequences, for example our customer may have made commitments to their customer on the back of the commitment that we have made. If we let our customer down, our customer will be letting their customer down. This is a lose lose situation if I ever heard one. Simply put, do what you say you are going to do and do it when you say you are going to do it.

If you can’t do what you have agreed to, make sure you let the customer know as soon as you are aware that you can’t deliver. By doing this, you are ensuring an open and honest dialog is maintained and you are giving the customer a chance to do something about it before it’s too late. If one of our customers is experiencing a problem with their software, we may set the expectation that we will be able to solve it before the end of the day. Our customer might then start working on something else, happily trusting us that we will solve the problem. 30 minutes later we may realise that we’re not going to get it done. I realise that it can be difficult to tell a customer that what you agreed to can no longer be achieved, but by telling the customer right away they may be able to achieve their objective another way e.g. paper forms could be used rather than the unavailable website.

My final point is to ensure that you are realistic in the expectations that you set. The best way to form a lasting relationship with a customer is to give that customer confidence in you and allow them to trust you. I was once asked if we could do something by a given date and I told the customer that I could, I said yes and nodded my head. The customer then said “Ok, I understand that you’re yes men – can you really do it”, to which I replied, “yes” J. The phrase ‘once burnt, twice shy’ comes to mind – this customer had been let down by another supplier in the past and now didn’t trust my judgement as a result. I’m pleased to say that the customer was delighted when we delivered exactly what I had agreed to and exactly when he wanted it. We now have a great relationship with this customer, we communicate openly and frequently and, above all, we trust each other and are able to depend on commitments made.

A typical customer of iMeta is a large international bank or other financial institution. A typical system that we build might be a bespoke web based application, taking legacy data from a mainframe backend system and allowing the end user to view and interact with that data online. Our customers come to us because we have considerable experience and a proven track record in the domain in which they are experiencing difficulties. Often such customers have pre-conceptions as to how something should be done or how it should take place – usually these pre-conceptions are absolutely correct and justifiable, but from time to time, someone requests something that’s not ideal. If this happens, it’s important to work with the customer to understand the problem and to work towards the optimum solution.

For example, I recently worked with a customer who had storage issues. Their database had grown to the point that the disk that it was housed on was soon to be full. The simple solution would be to move the database elsewhere, or to remove some data from the database so as to reduce its size. Unfortunately the customer did not have any space elsewhere and considered it not to be possible to remove any data. Instead they asked us to undertake considerable development to allow their data to span two completely independent databases. This would have taken a considerable amount of effort, would have introduced unnecessary technical debt into the application, and worst of all, would have adversely affected performance. I investigated the problem and established that SQL Server would be able to split the databases through partitioning, a much better solution than implementing this within the application, however it would have still required a considerable effort from iMeta to design the partitioning and performance would likely be impacted. Having considered all of the options, I eventually recommended that the customer purchase additional disk – this was the solution that offered the best value to the customer, would have been the quickest to implement and did not introduce any additional technical complexity.

It wasn’t what the customer wanted, but it was arguably the best solution to the problem.

Just a quick one this week. Spell check your e-mails! There’s nothing more unprofessional than sending e-mails with spelling or grammar mistakes in them. It makes the person sending it look lazy and un-engaged, especially considering how easy it is to spell check text on a computer these days. Just make sure it’s spell checked before sending – no excuses.

The other one to watch out for, and I’ve fallen into this trap before, is a typing mistake that results in a valid word, just not the word that you intended. I had been working on a problem for a customer all day, finally managed to establish what is happening, how to solve it and then came to write an e-mail to explain the situation. I’ve started with “Dear customer, I’m pleased to say that your website is not working. The problem was ...” I wrote the word “not”, but I intended to say “now” – my sentence had a completely different meaning from its intended meaning. My advice: read it from start to finish before sending it – don’t just rely on the spell checker.

My support team and I are all technical people. We are all capable of writing well structured and thought out code, of thoroughly testing that code and of providing it to a customer in a release to solve a problem; however, even though each person is able to do this by his or her self, I can’t express enough the importance of team work and peer review to the way in which we operate.

The support team at iMeta is ring fenced from development, this means that we are self-sufficient in terms of skills, knowledge and expertise – we don’t need to bring developers in to help us to solve technical problems. This also works well for our customer, who is able to build up a relationship with a fixed team of people and are not forced to work with a developer who has been assigned to support just for that day. Things usually work very well on this basis, our developers are insulated from support, our support team are able to directly solve the issues that are raised with them, so have a real sense of achievement from their job and our customers know who they are dealing with and have consistency between issues. Things usually work very well...

From time to time something will come up that is either very technically complex, very difficult to understand or follow, or that involves a technology with which the support consultant has limited experience. When this happens it’s important that the support person is well supported and knows where to turn.

For my team, the first port of call is other members of the team. We all regularly discuss the problems that we’re dealing with and use each other as sounding boards for ideas. This serves several purposes, firstly it ensures that nothing is missed because everything is peer reviewed, it allows for someone else to take over in case of sickness or other absence, but most importantly, it ensures cross-fertilisation of ideas amongst the team.

Occasionally something comes up that no-one in the support team is able to solve. When this happens we know that we have the full technical resource of iMeta to fall back on.

The very last thing that you want to happen is for your support people to be stuck on a problem and have nowhere to turn. This is dreadful for the support person - they will become de-motivated very quickly; for the customer – they are waiting for a solution to their problem and to the software house as a whole due to the lost time and reduced productivity that would result.

My advice, make sure that your support team know where to turn, who to turn to and when to turn there.