By Shalin Hai-Jew, Kansas State University 

In higher education, there is wide reliance on a suite of technology tools for virtually all functions:  business processes, communications, teaching and learning, training, research, data analysis, documentation, remote lab access, and other applications.  To ensure that technologies are used appropriately and securely, the software makers provide rich documentation about the tools and various types of context-sensitive help and on-demand online video trainings.  

Figure 1:  Support (by Wokandapix on Pixabay) 

The institution of higher education’s ITS personnel also provide technology documentation, in-person and remote trainings, direct consultations, and other supports.  Many also have technology systems to enable help desk access.  These systems provide a central point of contact.  They enable access for authenticated users who have a right to the ITS services.  These systems enable the inputting of descriptive intake information about the issues that the individual is facing, with some close-ended questions and a few open-ended ones.  There is the capability of uploading screenshots and manuscripts or other digital files that may be relevant to the query.  

Requestors of services are asked when they are available and how they want to be contacted.  The information from request to resolution is documented, for training, for data, for administrative decision-making, and for institutional memory.  [The help desk system was built on a SIPOC model, with capabilities for the application of Lean Six Sigma management.  Managers who are aware of this approach may be able to more easily analyze inputs and outputs of various services and come up with methods to improve the efficiency of the work.]  Such information may be used for supervision:  who takes which tickets, how do they troubleshoot the issue, and how much time did they spend on the work? [Side note:  The statistics have their limits since some people will open tickets and never close them.  Some will work tickets without assigning the ticket to themselves.]  Where should resources be directed to provide service to the campus?  What are the most common challenges in using particular technologies?   What is documented for user consumption, and what is privately documented for internal use?  Such systems help increase the efficiency of service delivery.  The systems that are set up smoothly for common workflows…and that use familiar nomenclature among the staff…and that are aligned with staff needs tend to be better accepted and used.  It also helps to have thorough trainings on how to use the system, instead of just assuming people will know how to use the help desk software.  

Once the form is filled out, frontline Tier 1 support refers to the first level of support that tries to address user issues, and those at Tier 1 escalate to 2 or 3 depending on the user needs and what they find during their troubleshooting.  The general process may be seen in Figure 2, a cross-functional flowchart.   

 

Figure 2:  A General Help Desk Ticket Sequence (on an Escalatory Ladder)  

For each technology tool, the manager is the main lead, even if he or she does not have the most technology expertise around the tool.  A small team supports each technology, and they trade off taking the tickets.  Tickets can be self-assigned if one wants to take a ticket, or it may be other-assigned based on others’ assessments of who has the knowledge and skills to troubleshoot.  Depending on the complexity of the issue, multiple individuals across multiple teams may have to work a ticket.  

On any of these small teams, some are more active as others.  Some view the work through a pecking order lens, and they’ll let someone else take a ticket first.  There is some pressure not to “scoop” colleagues or get into a competitive situation around service tickets.  [I had a colleague once who wanted to serve the tickets for those who were higher officials on campus…and she would express anger if anyone else took any ticket that she thought should be hers.  She also wanted the tickets that involved her going to a particular office on campus that controlled data because that alliance could benefit her career.  She would set up new services so that others on the team would not get reminder emails, so she could select which tickets she wanted first.  She’s not the first person to try to use a technology system to her advantage.  However, that sort of behavior was observed by others, and her behaviors became part of her reputation.]  In some cases, the person who opened the ticket may have figured out a solution by the time anyone got to it.  In those situations, it makes sense just to close the ticket with a small note and not assign the ticket to the self since one did not materially contribute to the solution.  

That said, there is a huge benefit in taking tickets to learn about the various “use cases” for the tool and for an understanding of where the challenges reside. On the receiving end, a service provider reads the ticket, reads or views the attached files (if any), and troubleshoots the issue.  The individual may elicit more information from the requestor, or he / she may have a sense of the issue and communicate with the requestor (by writing , by speaking, by taking screenshots and annotating these, and so on).  Sometimes, the work involves going in as an administrator to various socio-technical and technical systems and making changes there.  If more in-depth work is needed, then a web conferencing meeting is set up for a direct consultation, with screen sharing.  At each phase, it is always better to share relevant information (vs. hoard it to protect turf).  

Ideally, the help would be in real-time at the point of need, but that is not reasonable given work, given split attention, and other facts on-ground.  

I have been the person calling in or creating a help desk ticket to get help with a technology about which I was not fully familiar.  I understand what it is like to be frustrated when a software or a system does not behave how I think it should.  I know how much I appreciate the understanding of a colleague who gives me the benefit of the doubt when I have a question (even if the question may not seem valid initially).  That memory of being a “client” is helpful when I am the helper because I have a sense of empathy.  I know not to take a person’s frustrated tone personally, for example.  I am deeply aware of the high probability of user error in most cases with technology systems (so much so that this is a truism in this space).   

In some cases, the user just wants the issue solved and does not want more information.  These users will contact the help desk again and again about the same issues month after month, year after year.  They don’t generally take notes.  They sometimes like to blame ITS for how they’ve set up their own courses or for their own lack of knowledge about technology systems.  Many such individuals do not avail themselves of live trainings on campus (or simply lack the time or bandwidth to do so).  

Recently, a client with whom I spent three hours working through her doctoral dissertation asked to reopen her ticket because she was not satisfied with the three hours of consultation.  Her pride would not accept that she was not such a technology wizard that she thought she was.  She had to transfer the blame elsewhere.  I asked her to open another ticket so that someone on the team could help her through Round 2.  There are times when contemporaneous notes (and event logs) are helpful, and this was one of them.  People self-reveal by what they say and do.  During the session, she wanted the name of my supervisor to give me kudos but was probably interested in trying to find a point of leverage to get the various additional help she might want.  In terms of "dangles," another to watch for involves those who offer money for additional support.  These instantly introduce conflicts of interest and are not worth the drama.  If one makes the introduction to another, then one also takes on liabilities if that does not work out.  The "just say no" makes sense here.  

Ideally, clients would attend the public trainings that are offered for the various software and technology systems, and they would take notes.  They would experiment boldly with the tools they use daily.  They would query Google when they have questions and vet the various links they find to something trustworthy.  They would develop a skillset to troubleshoot within the technologies.  They would share that expertise with their colleagues and students and others, so everyone becomes stronger and more adept.  And many do!  

Figure 3:  Crossing Redlines 

For those who provide trainings on a campus, and those who work tickets, it is important not to step over redlines.  For example, if one provides support for a statistical analysis software tool or two, that person should not also provide advice on data analytics or data visualizations.  If a person advises on an online survey tool, they should offer suggestions for how to conduct such research.  In other words, those providing help would not step into others’ purview or others’ projects. They should not be insinuating themselves into others’ work.  

Some people will expect “the help” to do their work for them.  They’ll expect a design plan for the uses of particular technologies  with certain functionalities, and then they’ll expect the IT staff to make their instrument for them…and then to take on all responsibilities if anything goes wrong.  If they are denied such help, they may make one ticket after another and complain broadly and loudly.  No matter, it does not make sense to create liabilities in doing others’ work.  For me, I don’t mind drafting a plan on how to set up a software or to troubleshoot what someone else has created, but I do not like the risks or the odds of working with someone who does not know the tool and will not take the effort to learn it and who thinks that he or she can just assign work to someone else by diktat.  I also will not take responsibility for work that other people have edited heavily because I’m not sure what they set up.  There is no shortage of people who will expect Tier 2 and Tier 3 help to call them at home at nights and on weekends…or to constantly go beyond in providing services.  Maybe the help desk interface gives people that sense that personnel are live personal assistants, technological concierges, and ‘bots.  One has to be careful about giving out one’s personal telephone number even while working from home in the age of COVID-19.  I do know some people who would mis-use the unlisted number.  [It makes sense to have distributed power for provisioning of capabilities, so there is oversight and double-checking.]  Many use a help desk ticketing system as a point of leverage through which they can coerce extra work.  [I’ve seen this with some graduate students but also some staff.] 

There are no one-button solutions to achieving complex outcomes, and there are many dependencies that technological systems have (and every setting has to be correct for something to work).  Those with simplistic understandings of a tool just assume all work is easy because they are not the ones doing it.  So where possible, it helps to share information about the processes and the logics behind certain actions.  Ideally, the client will master a tool and wield it powerfully and professionally and ethically in their work.  I never encourage over-reliance on IT help.   

Also, various clients will request access to sensitive data or greater role-based powers.  In these cases, they all have to go through the proper channels and acquire the right signoffs.  I have no interest in owning someone else’s misuse of technologies, if that occurs.  It is easy to point to policies and decline that sort of access.  

Some clients do not “close the loop” on a ticket by acknowledging that they read the solution.  They just go quiet.  Some will not even remember who they worked with.  They’ll write something like, “Someone told me…”  Others will be gracious and share their gratitude with a kind message or two.  

As a member of multiple teams addressing multiple software and technology systems, I have a sense of the differences between the different problems different users face with different technologies, whether an online survey tool or a learning management system or a qualitative data analytics tool or a social network analysis tool.  There are particularisms of user needs but also sometimes common challenges based on design quirks of the particular software or system.    

Figure 4:  Polar Fluoresced Grid 

Over time, I’ve also acquired a sense of how to best approach a request, based on client preferences.  If I need to take screenshots, I find it better to use my email account and paste the images inline than to upload the visuals into a ticket (simply because the system we use does not display the images inline and makes it actually hard to find the uploaded images).  The idea is to make the information most consumable by the clients.  An email does result in cc-ing into the help desk ticketing system ultimately, so the images are stored.  

A lot of support work does not end up in a ticket.  Grant work does not.  Data analytics does not.  Some editing work for particular professional contexts does not.  Based on the help desk ticketing system, only some consultations and work are included.  And that is fine.  

There are sometimes impolitic facts that also do not go into a record, simply because the information may not help things service-wise.  There are better ways to blow off steam than to create a snitty electronic record.  

Another lesson I’ve learned is that some clients do not like it when their tickets are closed too soon, and they’ll make it a point to “reopen” the ticket even if it is just to make a comment.  There is an art to finessing how to close a ticket.  I realize clients want their concerns to be fully addressed and heard.  

On the other hand, some leave their tickets open for days and months, and that messes up the data that are extracted from the system.  It makes it look like they've spent a lot of time working tickets.  That is an illusion.  

A while ago, I remember being surprised when one of my colleagues mentioned that he was reading the tickets that went by.   I had not realized that that was a thing.  Now, I’ve determined to document tickets with a little more detail, for the sake of the work, but also to keep at least one of my colleagues lightly amused.  

Shalin Hai-Jew works as an instructional designer and researcher at Kansas State University.  Her email is shalin@ksu.edu.