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.”
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!
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 34 business areas owning 224 categories and 1210 subcategories. There 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”
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.Preview (opens in a new window)
- 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|
|Operator||Operator||Yes||Hidden in Power BI|
|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|
|UniDesk Self-Service Form||No||Optionally can pre-assign a Operator Group, Category/Subcategory or allow operator to set these.||Very specific|