A few years ago, I worked in IT Support for a Fortune 500 company who specialized in auto, home and life insurance. As we worked on various IT projects, we often supported or reviewed much of the user acceptance testing – trying and testing the new code repeatedly before the product was released into the marketplace.
Even with thorough, extensive testing and attempting to get the test environment as close to production (or the marketplace) as possible, there were typically issues to deal with – either small or not so small. If you’re cognizant, experience is a great teacher and it wouldn’t take too many product releases before I took a more active role in the process. Therefore, before another application or update was released, I would talk with the developers and testers to get as much information about the product. This would include screen shots of potential error messages, potential quirky messages or any other input that may potentially assist the support areas. As I would gather much of this information, I would eventually pass this along to the first and second level support personnel in the various call centers. If I had time, I would explain what I had seen and heard.
It didn’t take much time before these areas understood my intent and appreciated the feedback – they had not gotten this information before from the developers at home office. In fact, by being proactive with the information significantly improved our support on all levels – these support folks became more cooperative and more committed to fix issues ASAP.
As time went on, I became more engaged with the support centers and still found most home office developers in our area were not focused on the issue unless it was brought to their attention. If there were 50 calls on the issue during a 48 hour period, they’d eventually fix their code but were not necessarily proactively “listening to the marketplace” to see if everything was Ok. They figured 50 calls out of 10,000 were not bad odds unless of course you were one of the 50 whose PC didn’t work properly after the update. Customer centric approach by some of these developers? Hardly – for some developers, their responsibility ended once the code was released.
As I gained experience and confidence with this approach, I gained more credibility among the developers so when a new release came around, I was ahead of the curve. They sometimes came to me to check on the status of the update. Overall, because of my commitment to customer service and getting the support material to the correct areas, the developers and testers understood my approach and over time were more likely to oblige. Sometimes, certain developers became more proactive by sharing their information directly with the support centers – a culture shift improvement.
Indeed, this approach did not positively affect all developers in their project initiatives. In other words, some were “too entrenched” or not customer centric to be more proactive or supportive of the support areas who dealt directly with the customer. Regardless, I was able to set a more positive tone for the majority of the department, which improved our relationship with both call centers. This meant that our partnership was improved between the areas — they were much more educated and quicker to share potential clues and feedback on the results of the update. Quicker feedback and specific error messages gathered by the support centers meant developers were notified earlier of any potential issues which meant any issues found as a result of the application update were fixed sooner than without having this proactive approach.