Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

ITIL Tattle

ITIL Tattle

Blog posts on ITIL and ITSM news and best practice from the ISG ITIL Team

Why More Categories And Subcategories Will Not Solve Your Reporting Gaps

“He uses statistics as a drunken man uses lamp posts – for support rather than for illumination.”

Andrew Lang

So you need to do reporting and you think that adding categories and subcategories will be the solution?

But what if you are wrong?

Sometimes the obvious go-to solution is not the optimal solution; neither for the University; nor for your team!

Not convinced?

Well why do you want to report? Is it to justify the status quo? Are your reports a lamp post to provide support for not changing? If so, and you are not willing to countenance change, stop reading now…

So you are still here reading! You are willing to change! (Or were you too annoyed at being told to stop reading? )

The difficulty with change is that it might turn out to be negative rather than positive. It might be retrograde. So we tend to stick with what we know. And to over-simplify into a model that fits our view of reality even if that means it clashes with everyone else’s!

So how does this influence reporting?

Let us first consider about over-simplifying. What if our over-simplifying was contributing to our complexity and unwieldiness? This is what happens with categories and subcategories. Whilst conceptually simple, if not curated, the subcategories proliferate often duplicated under several categories. Hierarchies make management simple but are inefficient.

Hierarchies are best left to data sets that have clear inheritance. Librarians have long used meta-data to describe assets (typically books) so they can quickly retrieve them. The system may appear more  complex than a hierarchy classification but is far more powerful. It does not require imposing an arbitrary lineage to the items.

Currently we have 34 business areas owning 224 categories and 1210 subcategories. There are 225 duplicated subcategories including 40 “Unspecified”, 33 “Other”, 9 “General”, 8 “Email”, 7 “Help and Training”…..

Of those subcategories 286 have not been used this year!

A devolved hierarchical approach to categories is not working. There is a role for the ITIL Team to drive improvement in this area.

An existing example of poor category-subcategory usage might be

  • Category= “[function] Request”
    • Subcategory=”Student”

The subcategory is redundant as the affiliation of caller would give whether a student (and whether they are distance, undergraduate  or taught postgraduate, and what school they are in).

The category is also redundant. The [function] is implicit from the Operator Group resolving the call. The word “Request” is redundant because it is covered by setting  to Call Type=Service Request.

Call categories and subcategories should avoid duplicating each other and what is already available from other call attributes.

Improving Reporting With Fewer Categories and Subcategories

Our service support data from UniDesk has information about the call, the time line, the caller (and therefore their affiliation, college and school), and the operator(s) (and therefore their operator group, affiliation, college and school). The Operator Group is indicative of the functional area

Additionally, when used the object and external number fields may provide very specific. These call reporting points are summarised in a table at the end.

Within Information Services, the Categories and Subcategories have been aligned with our Service Catalogue Portfolios and the Business Services, and now includes the Finance and Procurement portfolio business services hosted on behalf of Corporate Services Group. The important point is that Business Services can only belong in one Portfolio.

If a student phones to say they cannot log into Learn then the IS Helpline should categorise base on what service the student is trying to use.

  • Identify the caller against our registered callers – easiest way being to ask there username and type it into the username field. This ensures we have the Affiliation (UG,PGT,PGR including distance) plus their School and College.
  • Probably set the Call Type to “Incident
  • Set the Category to be “Learning and Teaching
    • Set the Subcategory to be “Virtual Learning Environments
  • The operator may be able to identify the root cause or may escalate. The root cause for such an issue could be Learn itself, or EASE authentication or MyEd Portal, or with the student’s Student Records. This can be put into the Object field once known.
  • Occasionally the requirement for some ad hoc tagging of calls is required. The External Number field is free text and may be used in this instance. This might provide the tag required later for the more advanced options of linking to Problem or Change records.

The subcategory gives us high value data of what outcome the user was trying to achieve.

Finer meta-data can be added using other tags – the form used for a service request, or the object behind the root cause of an incident. The Call Type can be reset to “Service Request” if it transpires the user has forgotten their password.


The University is complex. High level decision making requires consideration of how numerous datasets intersect. A leaner University approach to use of categories and subcategories, coupled with a greater use of other call meta-data has the potential to greatly improve the quality of data available for decision making and improve  the measurement of whether those decisions are beneficial.

The ITIL Team can provide expert advice on using the existing rich data sets from UniDesk intersecting with organisational hierarchy and user attributes. Further we can provide advice on how your future reporting needs can be addressed with small tweaks to existing process.

Appendix – Reporting Attributes


Attribute Type Attribute Mandatory Ease of Use In Reporting Reporting Value
UniDesk Categorisation Category Yes Easy Very Broad
Subcategory Yes Easy but hierarchical Broad
Caller College Yes Provided the caller is registered lots of useful data is returned. Unregistered callers or calls with caller field being a proxy for the actual caller provide little business intelligence. Note that Power BI reports roll up staff departments to School. Reports against school in UniDesk Selections require knowledge of level 5 Org codes for staff and visitors. Students are assigned to Schools. Broad
School Yes Specific
Institute Very Specific
Affiliation Yes Specific
Operator Operator Yes Hidden in Power BI
Group Yes Easy Specific
College Yes Easy Broad
First Operator Group No Available in Power BI, harder in UniDesk Selections Speciific
Call Record Data Type Yes One of: Incident; or Service Request; or Request for Change; or System Event
Entry Yes One of: Telephone; or In Person; or Email; or Self Service or Operator Interface or Web Form Specific
Brief Description Yes The free-form nature and very specific means this is not useful for aggregated data (exception being Quick Calls). Because it might contain sensitive data it is not shown in Power BI
Impact Yes One of: Individual(s); or Dept/Location(s); or University Specific
Urgency Yes One of: Normal; or Higher; or Highest Specific
Priority Auto This is derived from Impact and Urgency Specific
Created Date Auto When the call started Very specific
Completed Date Auto When the call was Completed Very specific
External Number No Free-form field to record an external reference number Very specific
Line Auto Whether the call is at first or second line Very specific
Escalated Auto Whether the call has been escalated Very specific
De-Escalated Auto Whether the call has been de-escalated Very specific
Feedback Rating User Optional How the user rated the service – 1-5 stars. Soft metric
Linked Attributes Object No Object can be linked irrespective of Category/Subcategory Very specific
Standard Solution No Tied to Category/Subcategory so provide an extra tier to regular activities, but hierarchical Very specific
Problem/Known Error No Require the call to be linked but gives provides rich business intelligence Very Specific
Change No Very Specific
UniDesk Self-Service Form No Optionally can pre-assign a Operator Group, Category/Subcategory or allow operator to set these. Very specific

1 reply to “Why More Categories And Subcategories Will Not Solve Your Reporting Gaps”

  1. rgormley says:

    The UniDesk national service also offers advice on how to create good categories:

Leave a reply


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.