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.