The problem. Unreliable tagging system for chats.

The Database has a lot of information about every user interaction (Let’s assume chats for simplicity). And among some other things, we store tags. These tags are manually added -taking less than a second- but also suggested by a bot / learning system, so the operator has several options:

• They can add a tag to the interaction by typing a command “/tag tagname” at any moment in the chat tool/application.
• When the chat ends some options are displayed based on a predictive analysis bot and the chat operator just needs to click on those making sense.
• Chat transcripts remain visible. From the transcript you can either select one of the preselected tags by clicking on them or add a new one by writing it on an open field.

Tags sound awesome to filter interactions so that we can analyze data and extract knowledge from that data. But we discovered we couldn’t confidently use tags because of a lack of systematization in the chat tagging:

• We had 1400 tags, some of them overlapping, duplicated, with different levels of specificity…
• These tags had mixed up analysis axis. Some of them had to do with the chat topic(s) (domains, plans…), some of them were flags-like (issues in connection…), some of them were about the reason for contact (bug, cancelation…), some of them were contextual (the system we were looking for, the plan or subscriptions the user had).

So

• As it is impossible to remember all the possible tags, 1/3 of the chats were untagged. 1/3 more were just tagged once and frequently using a not very explanatory tag (general tags, tags about the plan the user has, flags…)
• Redundant or even inconsistent tags are frequently used in chats.
• The predictive analysis bot, that bases its predictions on the latest chats could work better with better and more consistent tagging.
• The list of available tags contains varying subjects, intentions, levels of details and purposes. This makes really hard to plan methodical analysis.

Solution. Create a new tags taxonomy + prune or clean up the list of tags

Using tags is a solid foundation, but in order to fully understand customer demand, we need to assure we cover all the axis or dimensions we could be interested in analyzing. We need information about the context (System/app version, browser and also subscriptions the user has), the topic(s) the interaction is about, the reason for contact (cancelation, bug, needs info…) and also keeping a space for flags that can be useful in some analysis.

So we needed to 1) create a tag taxonomy for support interactions and 2) to reduce the number of tags. The final aim is to extract more structured knowledge from interactions using tags as selectors. This by keeping the backward compatibility.

This post covers the taxonomy proposal.

The implementation. A taxonomy in 3 axes. Context, Reason for contact, Chat topic.

My proposal was a taxonomy composed of 3 dimensions (Each one possibly represented by several tags).

• Context. (Contains at least 1 tag) Context dimension tags explain the kind of user / plan / device / application or service -in case there are several- we are dealing with. E.g. Plan_Pro, App_Android.
• Reasons for Contact. (1 tag, mandatory) This should be one of a reduced list to be created by Support Operations team and, or, any other team that is going to extract value from this axis (possibly the related marketing team).
• Interaction Topic. (Any number of tags, including 0). Interaction Topic would contain a description of the interaction topic(s), trying to be as accurate as possible, not being redundant. It could also contains flags.

Implementation. Dimension: Context

Context is crucial to understand the interaction and it is likely to be likely automated. The system should automatically fill these for the support rep. Some examples of Context tags:

• One tag to describe the subscription the user has: subscription_free, subscription_pro…
• Possibly, if this makes sense and it is relevant, Tags to describe the system the user is asking from (OS, device, Browser…).
• Context flags. To mark chats with connection issues, when the system is auto-translating an unsupported language…

Implementation. Dimension: Reason for contact.

The tagging system should offer a short number of alternatives as a previous step to end a chat so that the operator can select one of them in one click. Reasons for contact should be agreed between the teams that are going to tap into these analysis/search criteria and they could contain:

• Bug – Customers contacting us due to an issue in our product.
• Product Gap – Customers contacting due to an area of our product which is difficult to understand / use without our help.
• Customer Education – Customers just need a hand with something in our product or service.
• Feature request – Customers asking for a new feature.
• Downgrade/Refund/Cancellation – Customer willing to stop their relationship with us 🙂
• Presales or information chat.
• Other –

Note: Checks on ‘Other’ tag usage would be useful.

Implementation. Dimention: Topic

At the end we would also need to select a topic. This topic should just contain one or several tags explaining what’s the chat about. This tags should be selected from a list of possible options that must be kept clean and short (another post on this).

So

• We can select any number of topic tags (0 included).
• We should use the fewer possible number of tags to accurately describe the topic.
  • No repetitive or redundant tags
  • No excessively generic tags
• A team should periodically check chats to avoid unuseful/misdirected tags and update the list of possible tags.

Exception. Flagging tags (Not topic related but that could be used to extract information or prepare samples to be studied or compared. Some of these flags could be used to temporarily highlight chats related to a new service we added or a change in the interface, to mark chats used for training purposes, chats were we offered a coupon…