By: Tony DePrato | Follow me on Twitter @tdeprato
Recently I was reading a Technology Directors’ forum, and noticed that a few very well established schools were explicitly looking for people to assist them in improving their technology support system (Help Desk, Help Tickets, etc.)
Reflecting on how I design and implement such systems, I began to wonder if these schools have looked at the core foundation issues that cause problems in systems that support a variety of tech-ecosystems and networks.
Why Does Anyone Need Tech Support in 2018?
The question may seem obvious, but this question should be asked every year: Who actually needs support and why?
Why do teachers need someone to come to the classroom to help them? Is the equipment old and/or inconsistent? Is the classroom design too complicated? Does the classroom equipment not work well with the teacher’s issued device(s)? Are students unable to use or manage their devices? Are the deployed software and services too difficult to master?
For example, if a school is running Google Apps for Education or Office 365 for Education, is the school running these newer solutions using and old model? That would cause many problems for end users. End users would be trying to follow an internal plan, that conflicts with the external supplier’s solution. Google and Microsoft are external suppliers, and they do have recommended implementation plans. In this case, the school has created a problem that will now need support.
The truth is, tech support and training are not the same thing. Asking support staff to execute tasks that an employee is required to do is a massive use of support time. The support staff is not the end user. Meaning, the support staff person is not a teacher. This means they will be very mechanical about explaining how things work, but possibly not very practical. Many issues are strictly job related, and require training from peers, not IT support staff.
The goal of anyone who is planning technology support, or facilities support, should be to eliminate the need for support. Expanding support around problems, will simply make those problems worse. Problems need to be eliminated to reduce the need for regular support.
Why Do Tech Support People Seem Apathetic and Annoyed?
Tech Support is actually a proper career. There are people who choose to be, and are employed as, tech support engineers or specialists.
In most schools tech support is usually an additional duty. Schools often have employees who are systems engineers, data base specialists, etc. assigned to do tech support. Why? Because, after all, if you have an IT job you can help people with IT. If that logic were true, every biology teacher could teach physics, and possibly serve on an ambulance as an EMT.
When people are spending most of their time away from their primary role, or outside of their primary comfort zone, they can develop a sense of resentment. In addition, people working outside their primary role will tend to make more mistakes doing other tasks. These mistakes often lead to public and unprofessional language exchanges. The cycle leads to further demoralization, and creates an environment of apathy.
The Way Forward
Over the years I have developed a few simple rules to handle support issues:
- De-personalize the process
- Divide-and-Conquer
- Follow-up Often
- Predict the future
De-personalize the process
The worse thing you can do is use personal email for tech support, or facilities support. There are some systems that work with a group email address ( eg. [email protected]).
However, even those systems trick the end-user in believing the email is going to a person. Email request systems, at least professional ones, route based-on criteria; or get posted in a list until a person delegates the work to someone.
The basic rule to follow is to use online forms or support groups (like Google Groups). Make certain individuals are not connected by name when they give support. Never allow teachers, or other stakeholders, to use personal email addresses for routine support.
Divide-and-Conquer
Support needs to be assigned to the person best suited for the job. Although some support can be generic and auto assigned, it is best to have routing system to send certain requests to certain people. For example, I have a form that has PowerSchool as an option. If someone selects PowerSchool, the request goes to the best two PowerSchool support people on staff.
Follow-up Often
From the moment a ticket is submitted, the end-user should automatically get a confirmation their problem is in process. When the problem is solved, they should get a notice. If their problem is pending for some reason, they should get another notice. If the issue is not solvable, the end-user needs a personal email, phone call, or face-to-face visit to explain in detail what is happening. Complaints from end-users are often regarding a lack of communication.
Currently, my support form tells each user what their number is in the queue. This small feature has been very well received.
Predict the Future
This is not as mystical as it sounds. Support issues should be collected as data. This is another reason email is a bad option, unless the emails go into a categorized database. Patterns emerge in the data. Patterns can be used to find the next problem.
Sometimes technology fails in a single instance, but usually technology failure happens in batches or waves.
If you would like to know more about building custom and free Support Systems with Google Apps and Office 365, please contact me at: [email protected] .