View all Blog articles

Posted on 24 April 2019 by

By Richard Lawrence-Allen


Contact centres deal with data, a lot of data. Every customer interaction an agent has will generate new data, both about that specific customer, their most recent experience with the company and, typically speaking, general feedback as well. To handle all this data there are many different software options available to contact centres that can be useful, and different software can excel in different areas, so it is up to each individual centre to decide upon the best technology package to use based on their current needs.




However, the nature of a contact centre is somewhat fluid, adapting its practices to fit changing client needs and new clients that are welcomed into the business. This can mean needing to adopt new software systems and databases to handle new processes that older systems can’t, forcing contact centres to use two systems in tandem. For example, if a company decides to introduce a new loyalty card, rewards or voucher system that its previous software is not equipped to store information about. This dual database work can also occur when a contact centre changes senior management teams or is sold on to another company. The new management or business owners wish to work with technology that they have used in the past and so introduce it to be used in addition to the legacy system or systems in place.




Standard newer systems don’t simply replace older, legacy systems typically speaking, but instead work alongside them. This is often because newer systems can’t always communicate with older ones, or because newer software, while handling new data sets, can’t always accommodate the entirety of the previous data fields of the systems already being used. Using two or more database systems is obviously not ideal as it will inevitably require agents to be trained to use multiple pieces of software, elongating training times and as such training costs. This can often be unavoidable though.




The biggest issue with using multiple data management systems however, is not the amount of training time needed, but how the data set is analysed as a complete overview of company efficiency and customer experience. Having data stored in multiple locations, with some information duplicated across systems, and some data not, means thoughtful data analysis becomes much harder. Creating data reports from multiple sources can pose several potential issues. Where relative data is stored in separate locations there are dangers of incorrectly linking duplicate data elements as well as retrieving outdated information that has been updated elsewhere, leading to use of incorrect information in final analytical conclusions.




The best way to avoid these types of issues is to introduce this use of a single source of truth (SSOT) system; this is something that structures information models and associated data schema into a single reference point ensuring each data element is stored only once in this primary location. The SSOT system is then able to update data element changes across the entire multi-platform system without any data being lost or duplicate examples of data processing being forgotten.




Using an example seen across a vast array of contact centres, an SSOT set-up would allow a single place to store all information regarding each individual customer they deal with. This information would include, current status of orders in-transit and processing, prior customer complaints or feedback, length of time spent as a customer of the company, total spend value, multiple delivery addresses and payment details, reward points accrued, and any other data that may be required. Having all of this information stored as a SSOT allows for it to be readily accessible and reassures an agent that the information that they have is both complete and fully up to date, allowing them to give the best service possible.




Despite their benefits, many contact centres choose not to adopt SSOT systems due to the initial capital that they require. Moreover, achieving an ideal SSOT structure may not always be possible with all pieces of software. Many organisations purchase “off-the-shell” software packages when buying information systems, and oftentimes these packages cannot be modified in significant ways to accommodate the necessary switch to an SSOT system. This can also be particularly difficult when it comes to systems that need to communicate through different companies such as a vendor and an outsourced warehouse distributor, where one organisation cannot guarantee the compatibility of systems that they use with the systems of the other with the SSOT location when communicating. This could mean the need to purchase additional software to combat this with more global compatibility or introducing further, more complex, IT architecture, increasing initial costs. This still would not necessarily result in a truly complete SSOT system at this moment in time however.




Regardless, the benefits of striving for an SSOT system are clear, especially when looking at long-term data solutions, and customer engagement and retention. Individual contact centre or vendor simply needs to run a long-term cost-benefit analysis of the capital it would take to implement this idea before committing to it.