This is a public Idea Center  publicRSS

Idea

    2 liked this

    Ability to extend purge of chat data longer than 180 days
    Idea posted October 5, 2017 by Kristine TannertWhiz, tagged Chat, Reporting 
    50 Views, 4 Comments
    Title:
    Ability to extend purge of chat data longer than 180 days
    User Story / Description:

    We’d love to retain our chat data for longer than 6 months. Currently there are several agedatabase utilities that purge chat data after 180 days at the maximum. 

    This was our first full year of using chat, and like many businesses, we have seasons that are heavy in customer traffic and seasons that are light. So we were looking forward to digging into the data and seeing how our KPIs and other metrics looked throughout all our seasonal ups and downs. Now we’re not going to be able to do that since the info is getting purged after about 6 months. 

    Of course, we have the incident records for the chats, and I'm very glad we do, but the incident won’t tell us abandon rate, expiration rate, handle time, wait time, and so on.

    I understand the chat tables fill up very quickly, but there are still business needs to look at more than 6 months worth of chat-specific data. Even if the data were archived to some secondary table and we had to jump through a few extra hoops to pull it onto our reports, it would still be so helpful in understanding the health of our chat program and making improvements. 

    Comment

     

    • JessicaB

      Hi Kristine,

      What values are you looking for when it comes to the different Chat Cloud Service Data Purge settings?

      We don't have any changes to the settings on our roadmap within the next two releases, but I'm very interested to hear what you're looking for (what's your ideal?) and other needs you might have around referencing the data.

      --Jessica

       

       

    • Kristine Tannert

      Jessica - 

      Thank you so much for asking. One of the reasons Insperity chose Service Cloud was the robust data set behind chat. Our contact center uses the chat data as part of their QA program  - they look at things like handle time, wait time, wrap up time as a way of scoring and incentivizing agents (they also audit some transcripts and review survey responses, which could still be done even with current purging functionality, but efficiency is always a component). In addition, like many businesses, ours has some very high peaks during certain seasons and certain days of the week. We need to look at the same KPIs during peak seasons and days (for example, the month of January is a busy time for our Contact Center, so are Fridays) to do forecasting as well as to find areas for process improvement and agent education. The data that's purged from chats around dates created, initiated, wrapped up, etc. is incredibly important when taking a pulse of where we are and where we should be in our efficiencies goals. 

      Ideally, we would like to hold on to all the chat data indefinitely. Even if the data were archived to some secondary tables but they could still be accessed in Reporting/Analytics and joined with more recent data still in the primary table, it would be quite workable. Again, one of the great features of Service Cloud chat is the rich data set under it - we don't always know what kinds of questions we're going to ask of the data until we need to ask those questions, so it's wonderful that we can likely find all kinds of granular details and trends given the amount of info being logged on each chat. It's hard to say "Oh I want this exact table and column because I always measure XYZ." Life happens and we may want to study something else that you're probably already logging.  But when that's gone after 6 months or even a year or two, the chat product just feels less valuable and complete to us. Ideally, we just want to hang on to it in a way that we can mine it and analyze it later. So if those purging config settings were more like archiving settings, and there was documentation on how to access the archived tables in Reporting/Analytics and mash up the archived data with the more current data in the primary tables, that would be really wonderful. 

      Short of my ideal, it would at least have been good to know about the purging at the beginning so I could have taken steps to preserve the data outside of Svc Cloud. I'm guessing you might have other customers like us, who wouldn't have even thought to ask if data were being purged. I wasn't at my company during the initial implementation of chat, and got sort of dropped into it after the fact. Nobody on my team had much knowledge of Service Cloud. So I've had to learn via the community, knowledge, and a subscription to Oracle University (in between just learning the product by administering it) and I would never have thought to ask whether data was purged or look up knowledge articles on that, because I didn't know what I didn't know. It wasn't until my leadership team started asking for a look back at our recent chat launch (a little over a year ago) that I realized we had months worth of data just totally gone. This is how I learned it was being purged - not really a great way to find out. If this purge info were somehow more prominent to administrators who might not even think to ask that question, it might spur your customers to seek solutions sooner (such as porting the data into their own warehouses before it gets purged). 

      Thank you for asking more about this, Jessica. I'd be happy to discuss more about it any time!

      -Kristine

    • JessicaB

      Hi Kristine,

      I'm sorry these settings are limiting for you and I appreciate the additional information (it always helps to know a company's specific use case).

      Because I don't have updates to these settings planned for the next 2 releases, I would suggest keeping the reports as well as working with your CSM for options to store data longer than what is offered ootb today.

      --Jessica

    • Kristine Tannert

      Thanks again for responding, Jessica. I really appreciate your time. Hopefully sometime in the future, there will be something other than a purge that can satisfy data needs along with healthy performance needs in the product.