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.

At iMeta we take providing a fantastic support service to our customers very seriously indeed. We pride ourselves on the high proportion of customers who commission us to provide additional development for them, beyond the scope of what is originally delivered. This is in part due to the highly skilled, dedicated and experienced developers, testers and project managers that we employ, but equally important is ensuring that our customers are pleased, no, delighted with the support service that we offer.

My name is James Watson and I manage the support team at iMeta Technologies. I’m very fortunate to have a team full of dynamic high achievers to work with, however there are a number of things that we do to ensure that we maintain the exceptional level of service that we provide. Throughout this series of blogs, my team and I are going to try to share the secret of our success with you. Let’s start with the basics – know your customer.

By know your customer I don’t mean make them your best friend, go out drinking with them and send their children birthday presents, what I mean is know their business. You can’t clearly communicate with a customer on a support matter if you don’t know what they do, what their software does and what the consequences of what they are telling you will have on their business.

Make sure you keep up to date with each customer – this is easy with the customers that you speak with frequently, but much more difficult with those who you have very infrequent contact with. (I will discuss the need to maintain frequent contact with your customers in a later blog since this is very important for a number of reasons). It also helps significantly to know who you’re speaking with and where the fit within the organisation. A business user is likely to want a far less technical explanation of a problem than an IT administrator – it’s important to establish a rapport with the person that you’re dealing with and to give them what they need. (I’ll come back to this point later on too).

A number of our customers are large banks, insurance companies or businesses that provide fund and trust management services. Understanding the business of these customers can be a challenge due to the complex nature of what they do – can you explain to me what a non-default cash standing settlement instruction is? The more complex the customer’s business, the more important it is that you understand what they do and how they do it. This understanding can make the difference between providing an adequate service and a superb one.

I don't think this will be new to most people, but it's something that I came across recently and spent some time researching. The scenario here is that our customer has a business administration system in their office that is used to manage, among other things, details of their customers. They have a website that allows customers to log in and change some details. The website is hosted with an ISP and the administration system is kept in house. They are both use SQL Server 2000 databases. To keep the two databases in sync, two-way transactional replication is used.

We had some teething problems with this when it was first setup, but since then it has worked reliably, until recently. They had an ADSL outage to their office that lasted for a number of days (I think it started on a Thursday evening and was not resolved until the following Monday morning). When the problem was finally solved our customer noticed that replication was no longer working. The following error message was being presented on both ends:

Error in replication::subscription(s) have been marked inactive and must be reinitialized

We could have reinitialized as the error message suggests, but this was not desirable due to the volume of data involved – we would have been forced to re-sync the entire database which is several gig in size. The usual restarts and reboots did not solve the problem.

We knew that there was no problem with the data, all of the changes were queues in the transactions to replicate table, it’s just that replication wasn’t happening. I did some research on the subject and discovered that there is a status column in the MSsubscriptions table in the distribution database that indicates the status of each subscription. 0 = Inactive, 1 = Subscribed, 2 = Active. I also read that it is safe to update this status; it just puts SQL Server back in the state that it was in before the subscription status was changed. Depending on what the initial problem, this may not be what you want, but in this case, it is exactly what I wanted to do.

“Select * from distribution..MSsubscriptions” confirmed that this was correct

“update distribution..MSsubscriptions set status=2” run against both database instances solved this problem.

Why this hasn’t been build into the SQL Server I don’t know, but maybe it’s because it can be dangerious to do this if you don’t understand what you are doing and why.