Skip to main content

Welcome to the inSided Whiteboard!

 


In this release the main topic is using Post fields and our Post Field Analysis tool.

 

 

 

da31bc15-edff-49ce-80ce-950154cdc600.jpg

 


Transcript:
One of the main issues community managers find when reporting is that aggregate figures (total replies or total number of topics) are simply not detailed enough to, for instance, find out what the recurrent issues of their different products are, or not specific enough to give feedback to product teams about reported bugs, among other things.

I will focus on these two particular cases so I can make sure that the point about structured data get across and the benefits of the tool are clearer.

Take the idea of using Post fields for identifying recurrent issues that customers have in your community.

In this example I use post fields to Identify recurrent issues and sentiment at the time of posting.

Using this two categories, these two post-fields allows me to generate FAQs and in general content that is specially relevant for your customers and which can actually have an impact on your SEO. Categorising content according to Sentiment helps me to find out what the general attitude towards the community is, and going further it allows me to see how certain issues may relate to certain sentiments (both good and bad). This means that using post-fields I can find out whether there is a relationship between a product use and a positive or a negative sentiment.

Now, keep in mind that I am able to capture already all this information by using only 2 post fields. So imagine the amount of things you can learn if you would use 5 or 10 post fields. The potential for insights that will help you steer your community is enormous.

I will now pass to a different use for post fields, which I mentioned earlier and that is the use of Post fields to gather feedback and for beta testing. In this case let’s assume I ran a testing program and I want to use Post fields to structure the feedback provided by users who are testing my App. I really want to make sure that the feedback will be truly valuable to my product team, who is eager to know how the App performs before rolling it out to all our customers.

In this case I will use the following two post fields: Smartphone OS and Story Quality. Quality story meaning a more complete story, which in the case of testing is essential, because a better story will help my product team much more and will also help other testers who read it say “Yes, I have the same issue!”

With the first wants I will capture all IOS users who report the same bug. I can also compare them with testers who use Android and check whether they experience the same bug.

I use my second post field to see whether certain testers provide a better quality story than others. This way I will know who I should continue inviting to my testing program in the future or I may also learn that feedback instructions are perhaps unclear to some of my testers. Using both post fields I can go further and check whether iPhone and Android users provide the same quality stories or whether there may actually be a difference. This means gaining insights about the quality of the feedback that my product team is getting from my users, in order to make sure that good quality stories don’t bias my feedback, making them think that perhaps iPhone users have more issues, simply because they give better quality stories.

 

 

Hello @Daniel! Congratulations for the initiative! Great video 😎





At NOS we are using post fields since the very beginning. Just to have an idea, we have "tagged" more than 9 875 comments so far. We have the following structure:





1. Product: we have 11 sub-categories that represents the main products/services we have


2. Client´s issue: 16 sub-categories that better explain the real issue


3. Post type: either a suggestion or a complaint


4. Sentiment: positive, neutral and negative





Regarding the usage, let me tell you our main difficulties:


- is there a way to change all posts that were categorize with a specific PF (post field) to another?


- the reporting that we extract isn´t the best one... we would like to analyze the text, but if a user gives an "enter", the excel comes in an impossible way to make analyses (like pivots)





Is there any other advice you can give to improve our method so far?
Hi @tomasmouton please find my answer to your questions below:





Regarding the usage, let me tell you our main difficulties:


- is there a way to change all posts that were categorize with a specific PF (post field) to another?





There is no automated manner of doing this. The only way to do this would be to re-categorize all annotated posts with the new PF you came up with. The best however is to ensure from the start that the PF you are using are actually the ones you need to get the insights you want. I can help you out :)





- the reporting that we extract isn´t the best one... we would like to analyze the text, but if a user gives an "enter", the excel comes in an impossible way to make analyses (like pivots)





This feedback maybe interesting for our product team and in fact could be a suggestion to make in our ideation category.
Hi @Daniel!





Thanks for the answers. Regarding the first one, I would love to get the post fields right at the first attempt. But as you know, the company may have different interests across time... that´s why this could be a good feature





The reporting was already escalated to support. But if you could also pressure it... we appreciated 😁

Reply


Terms & ConditionsCookie settings