If you have not visited previous blog of this series, you may refer HERE. If you want to save time but still want to put this CS cheat code to practice. TLDR: The knowledge pyramid is a practical mapping tool that allows for you to model any relationship between actionable insights and unprocessed data.
Considering now you know the knowledge pyramid which talks about layers, properties of individual stages of data journey from data to information to insights/actions. Now let's discuss this in the CS admin context.
CS Admins are usually given one of two scenarios when working on building out automation for their teams. Either they are given a goal (trigger a call to action) and told to figure out how to use the data to do it. Or they are given different data sources and told to figure out what kind of insights and calls to action they can create. The problem posed might seem the same but the approaches to solutioning have very different pathologies and potential risks to avoid. Let’s first take a look at INDUCTIVE SOLUTIONING
Inductive solutioning is the approach applied when you know what data you have but not sure what insights you need to generate. A great example is you have contract data for all customers over the last year. You have fields like date closed, closed outcome and total. Your leadership team has asked you to review the data and find out what kind of automation you can build to power a set of CTAs for the team to improve consistency of renewals. In this scenario the key to success is to be able to find all of the data available and what are the current relationships in the data that you can leverage to build the most impactful insights. In your review of the data you have you are going to first look for all of the relationships you have today. If you are missing key relationships you need that still gives you initiatives you can propose to fill the gap over time. After review you have confirmed that the contract data itself has a link to the account which gives you access to any demographic insights at the account level.
By starting with the relationship fields that you can leverage you now can begin to explore which fields are most populated and viable in further exploration for potential insights. Demographic fields like industry, lead source and segment are all great starts. These will help turn your raw contract data into information. But information alone as we learned before is only somewhat useful. Now it’s time to add context. This is where you are going to then explore what are the fields that I can use to give these insights priority. Most companies have some form of manual fields that are logged by the CSM team to measure things like risk , status, current sentiment, is escalated. These fields are the ones you need to give value to which insights are more actionable or not. This is the power of Inductive solutioning it helps you optimize for impact.
|WHEN TO USE:||When you have few data sources to combine and also but are unclear about what can be achieved with your data|
|PROS:||Allows you to produce insights that are more impactful|
|LIMITATIONS:||Can suffer when data is sparsely populated|
|RISKS TO AVOID:||Avoid leveraging fields that are not regularly updated or relatively accurate|
Now that we have discussed how to discover insights when given any different data sources. Lets now look at the opposite scenario: DEDUCTIVE SOLUTIONING
Deductive solutioning is the approach applied when you are given specific insights you need to generate but you do not have a clear direction of what data sources you will use to create it. For this example let’s consider you have some support ticket data in zendesk. Some marketing data from marketo and some of the same contract data from before.
This time your leadership team has asked you to create a risk playbook for clients that have support risks in zendesk. In this scenario you know what your goal is. But the question is how do you use the data you have to power a risk playbook that is not accurate. A junior CS admin would say this is easy. Just use the support data by itself. However the more seasoned CS admins are reading along and can already tell what could go wrong. The key here is when creating any risk playbook it is important for that playbook to be not only accurate but factor in prioritization. For this reason it will be critical that you solution incorporates context from other sources to be able to make sure that the playbook is not just business work.
This is where deductive reasoning comes in. You are taking your problem and exploring the potential context needed to make the resulting insight actionable and useful. Which is in turn the main value of deductive solutioning. It helps you make insights you need to be generated from multidimensional sources more actionable.
|WHEN TO USE:||When you have multiple data sources to combine and also have a clear outcome to achieve with your insights|
|PROS:||Allows you to produce insights that are more actionable|
|LIMITATIONS:||Does not work well when relationships mappings between data sources are not logged|
|RISKS TO AVOID:||Avoid leveraging data sources that do not have proper relationship fields mapped|
Now that we have learned the difference between inductive and deductive solutioning. Time to put these tools to use on at your organization. You can contact us HERE and will send you the Knowledge Pyramid worksheet. Good news is we have built both of these frameworks into our flagship product. So if you would like to save time and get auto generated insights using these concepts click HERE to schedule a time to connect and sign up for our Dataplant beta program. Either way good luck solutioning out there and until next time; Stay nimble my friends!
If you enjoyed this article, please subscribe. Let me know your thoughts at sam @ thedataplant.com or share this article with someone else you think will find it valuable. I have lots of other blogs and insight rich content on our site or on the way for you to enjoy. Until next time. Sam C.