Get rid of case metadata!
In traditional case-tracking systems, we are urged to capture information in a structured manner so we can report on it. Sadly, case-tracking systems quickly become archeological digs, where each field reflects a particular layer of history and cleanups are all too rare, leaving cluttered screens, poor-quality data, and frustrated users.
In the future, AI tools will free us from much of the drudgery of maintaining metadata. For now, let’s do some late-spring metadata cleaning with this checklist. Remove fields that are:
- Not used in any critical reports. For instance, you may have a field that tracks how the case was opened (chat, phone, portal, etc.). If one of the values is “Fax” [all the examples I cite are true, recent stories from FT Works projects; to protect the guilty, I will use no names], it’s a hint that no one is using that field and it can be removed.
- Duplicates or near-duplicates of others. We often see a field that tracks root cause (excellent idea, very useful for reports!) and another field that tracks “disposition”. For instance, the poor support engineer has to choose “how-to question” for the root cause and t”showed the customer what to do” for the disposition. Surely one is enough, right?
- Known to contain unreliable data. This is a very common problem, often combined with #4, below. We routinely see a “next update due” field that contains long-past dates for cases that are actively worked. If the data is routinely invalid, why track it?
- Filled out manually. Manual input creates lots of extra, boring work and yields poor validity to boot, as noted above. A typical example is haphazardly-chosen case categories because there are too many levels and too many choices at each level. Unless your name is Erin (hi, Erin P.!) and you are able to enforce perfect categorization across multiple levels, jettison a level or two in your category tree.
- Used for a minority of cases. For instance, identifying the operating system of on-premise cases is important, but it’s irrelevant for cloud cases. If you have a handful of on-prem cases, consider removing the field entirely (or at least remove it for the cloud cases).
- Not clearly labeled. We worked with a vendor recently that had a checkmark labeled “escalated”. Some support engineers thought that meant escalated to engineering; others thought it meant escalated formally, to management; and a few used it as a private time-management aid! Needless to say, the quality of the data left something to be desired, all because of poor labeling. Perhaps it makes sense to keep the checkmark, but not without a label change.
- Cluttering the engineers’ screen. Even if a particular field is needed, reliable, and properly labeled, it may not be useful to see. For instance, displaying the initial response target for an individual case is useless once the initial response has occurred. In this situation, you may not want to remove the field entirely (since it is automated and useful for reports), just hide it.
- Barriers for customers. Are you asking customers to enter 3 levels of categories when they create a case? They hate it, and will likely do a poor job of it (see #4). It may be a matter of hiding the fields rather than removing them–although I doubt you actually need 3 levels of categories, regardless of how vast your product portfolio is.
Want to brag about how many fields you trashed? Enter a comment, please.
