Advice on Structuring Root Cause & Sub Root Cause Fields for LMS Support Tickets

[manuelgamit]

We’re working on improving how we track and analyze support tickets for our internally hosted (but externally developed) Learning Management System. The platform also hosts educational resources and CMS pages.

Our team uses ServiceNow to capture ticket data via a custom app built around a form. While we already have a well-defined set of request types and subtypes, we're now focusing on refining our root cause and sub root cause fields to get more actionable insights.

We've come up with a solid list of root causes (e.g., Bug, System Misconfiguration, System Limitation, Solved by User Education, etc.), but we’re struggling to strike the right balance for sub root causes — not too specific to avoid unmanageable lists, but not so open-ended that we lose the ability to filter and report effectively.

Our goals include:

• Identifying the most common bugs to communicate clearly with our vendor.

• Understanding system limitations that could lead to change requests.

• Highlighting UX issues that could be improved internally.

We’re considering not using sub root causes for categories like “Bug” and “System Limitation”, and instead adding a URL field linking directly to the relevant vendor ticket or change request.

Has anyone tackled a similar challenge? Specifically:

• How have you structured root cause data in ServiceNow to drive meaningful insights?

• Do you use sub root causes? If so, how do you manage the level of granularity?

• Are there best practices for balancing structured fields with flexibility?

• Any advice on using links or references to vendor/CR systems from within tickets?

Any insights, lessons learned, or examples would be greatly appreciated!

Thanks in advance!

[StephenR0086629]

One approach I’ve used is maintaining a standardized dropdown list for root causes and linking sub-root causes through dependent fields. It helps avoid data sprawl and ensures better reporting. I’d also recommend setting clear definitions for each category upfront—otherwise, teams interpret them inconsistently. If multiple teams use the form, consistent training and examples are key to getting quality input.