Helpdesk Changes
A few weeks ago we introduced a new helpdesk system at Wauwatosa School District. I will tell you which product at the end of this post. Note - we, or I, do not get a kickback or benefit from posting the product name in any way whatsoever. I'm posting it because I like it and think it is good.
Before we get to that point though lets consider the cause and effect of what prompted the move from our old system.
We partner with a video training company. One of those that provides a host of production level training videos for technology applications that staff and students can view. That product allows you to easily generate a set of URL links for specific videos that you select. It gives you the html code for those links, nice and neat, so that you can then embed them into a document.
I was working with a teacher and, using that 3rd party site, generated links to a set of videos for her that were relative to the question she was asking. Her question was a fairly common one so I decided that it was good information to include in our helpdesk knowledgebase. Having a document in there with precompiled links would serve our customer base well.
Our helpdesk, at the time, allowed you to attach files to knowledgebase articles. That's ok but it wasn't intuitive for the end user. If fact it was kind of counter-intuitive. The articles had to say "open the attached file to view the links" and the attachments themselves were tiny little icons in the bottom right corner. Not cool - not when you are serving people who just want the answer and don't have time to try figuring out where that answer is.
So I opened a ticket with the companies tech support service and asked if embedding html into the body of knowledgebase articles was an option. If I could do that then the links would be right there in plain view.
"No"
That's ok. Was it on the roadmap or something that would be considered for inclusion?
"No"
Now....embedding html is a relatively simple thing to include in a web editor. It is highly common place. The simple statement of it not being considered bothered me. A lot. Not because the product couldn't do it (I'm ok with features not existing) but because they weren't considering it. I had explained in some detail why I was looking for it and how useful it would be but there seemed to be no interest in self improvement from the vendor. No statements of "its a good idea but it would require too large of an overhaul of our architecture". No statements of "we are coming out with a new feature that will serve that purpose better". Just a simple "No".
So that started me looking for alternatives and here is why.
The Wauwatosa School District Technology Services department is about customer service.....which means continually applying efforts to self improvement; Forever looking for ways in which we can improve the experiences of our customers.....teachers, staff, students, and families.....and our value to them.
If you think about it that's really the primary purpose of all tech support departments. Granted, the weighting of importance may be greater in some environments than in others but when it comes down to the root of it all it's all about customer service. Every business, company, organization, institution, and so on, has a product that they are seeking to produce be that the education of a child, a widget, a service, a beverage, a vehicle, etc. It doesn't matter what it is....every organization is trying to produce something.
More often than not the organization wants to find the happy medium where they can produce that product at optimal cost and with maximum effectiveness/quality. Technology isn't in those environments because it alone produces the product - technology is in those environments because it helps produce the product in the desired optimal/maximum quality manner.
Lets look at schools. The tip of the arrow - the thing that gets things done - is the classroom; The most critical part of that classroom, of course, being the teacher. The classroom needs the teacher but the teacher does not need technology to teach. Technology often makes it easier. Technology often enables them to meet their goals in an ever increasingly demanding environment. Technology often lets them do things they could not do without it. Technology often optimizes their time. But at the very core - they can teach without it. No doubt it would be a lot harder.....but it can happen without tech. It's just that in some situations it would be inefficient, less engaging, and, at times, counter productive not to use it.
Tech is in schools to help schools achieve their goals. That's it. No grand vision statement needed. I have seen district tech departments with 2 page rhetorics about why they exist and what their vision for the future is. That's nice and all but the simple and basic truth.....the real heart of the matter....is that tech is there to help the teacher/school/district do what it needs to do in the best way possible.
And that means not just responding to calls for help but also proactively seeking out opportunities to help the district do what it does better. It's a cultural thing and one we work hard at in my department to maintain. So....if we are working to improve in the services that we offer to our customers then my expectation of any product/service/vendor that we invest funds with is that they are doing the same. That doesn't mean that I expect vendors to jump at my beck and call, I realize that sometimes things cannot be done, or may take a long time to get through change control, or are not even fiscally viable, but at least listen to valid suggestions or pleas for help and react to them.
So we jumped ship. We use Freshdesk now and I am very happy with the product. Perfect? No. Responsive to requests for improvement or features? Absolutely. Feature rich and full of things that make you think "boy - why didn't we do this ages ago"? Most definitely. I think it works so well because it is designed and created by people who have spent time as helpdesk support. They know what works for customers and those supporting them and have transposed that into their product.
Their startup story is quite a good read.
The best thing though - it has brought a level of improvement to our helpdesk processes (and backend reporting) that we have sorely needed for quite a while now.
And yes - we can embed html code directly into knowledgebase articles.
Update: Looking at their site it looks like Cisco just jumped on board with them. Just for the record......we did it first!!!! :)
Before we get to that point though lets consider the cause and effect of what prompted the move from our old system.
We partner with a video training company. One of those that provides a host of production level training videos for technology applications that staff and students can view. That product allows you to easily generate a set of URL links for specific videos that you select. It gives you the html code for those links, nice and neat, so that you can then embed them into a document.
I was working with a teacher and, using that 3rd party site, generated links to a set of videos for her that were relative to the question she was asking. Her question was a fairly common one so I decided that it was good information to include in our helpdesk knowledgebase. Having a document in there with precompiled links would serve our customer base well.
Our helpdesk, at the time, allowed you to attach files to knowledgebase articles. That's ok but it wasn't intuitive for the end user. If fact it was kind of counter-intuitive. The articles had to say "open the attached file to view the links" and the attachments themselves were tiny little icons in the bottom right corner. Not cool - not when you are serving people who just want the answer and don't have time to try figuring out where that answer is.
So I opened a ticket with the companies tech support service and asked if embedding html into the body of knowledgebase articles was an option. If I could do that then the links would be right there in plain view.
"No"
That's ok. Was it on the roadmap or something that would be considered for inclusion?
"No"
Now....embedding html is a relatively simple thing to include in a web editor. It is highly common place. The simple statement of it not being considered bothered me. A lot. Not because the product couldn't do it (I'm ok with features not existing) but because they weren't considering it. I had explained in some detail why I was looking for it and how useful it would be but there seemed to be no interest in self improvement from the vendor. No statements of "its a good idea but it would require too large of an overhaul of our architecture". No statements of "we are coming out with a new feature that will serve that purpose better". Just a simple "No".
So that started me looking for alternatives and here is why.
The Wauwatosa School District Technology Services department is about customer service.....which means continually applying efforts to self improvement; Forever looking for ways in which we can improve the experiences of our customers.....teachers, staff, students, and families.....and our value to them.
If you think about it that's really the primary purpose of all tech support departments. Granted, the weighting of importance may be greater in some environments than in others but when it comes down to the root of it all it's all about customer service. Every business, company, organization, institution, and so on, has a product that they are seeking to produce be that the education of a child, a widget, a service, a beverage, a vehicle, etc. It doesn't matter what it is....every organization is trying to produce something.
More often than not the organization wants to find the happy medium where they can produce that product at optimal cost and with maximum effectiveness/quality. Technology isn't in those environments because it alone produces the product - technology is in those environments because it helps produce the product in the desired optimal/maximum quality manner.
Lets look at schools. The tip of the arrow - the thing that gets things done - is the classroom; The most critical part of that classroom, of course, being the teacher. The classroom needs the teacher but the teacher does not need technology to teach. Technology often makes it easier. Technology often enables them to meet their goals in an ever increasingly demanding environment. Technology often lets them do things they could not do without it. Technology often optimizes their time. But at the very core - they can teach without it. No doubt it would be a lot harder.....but it can happen without tech. It's just that in some situations it would be inefficient, less engaging, and, at times, counter productive not to use it.
Tech is in schools to help schools achieve their goals. That's it. No grand vision statement needed. I have seen district tech departments with 2 page rhetorics about why they exist and what their vision for the future is. That's nice and all but the simple and basic truth.....the real heart of the matter....is that tech is there to help the teacher/school/district do what it needs to do in the best way possible.
And that means not just responding to calls for help but also proactively seeking out opportunities to help the district do what it does better. It's a cultural thing and one we work hard at in my department to maintain. So....if we are working to improve in the services that we offer to our customers then my expectation of any product/service/vendor that we invest funds with is that they are doing the same. That doesn't mean that I expect vendors to jump at my beck and call, I realize that sometimes things cannot be done, or may take a long time to get through change control, or are not even fiscally viable, but at least listen to valid suggestions or pleas for help and react to them.
So we jumped ship. We use Freshdesk now and I am very happy with the product. Perfect? No. Responsive to requests for improvement or features? Absolutely. Feature rich and full of things that make you think "boy - why didn't we do this ages ago"? Most definitely. I think it works so well because it is designed and created by people who have spent time as helpdesk support. They know what works for customers and those supporting them and have transposed that into their product.
Their startup story is quite a good read.
The best thing though - it has brought a level of improvement to our helpdesk processes (and backend reporting) that we have sorely needed for quite a while now.
And yes - we can embed html code directly into knowledgebase articles.
Update: Looking at their site it looks like Cisco just jumped on board with them. Just for the record......we did it first!!!! :)
Would you explain the notion of an "agent" as used by this company?
ReplyDeleteSure - an agent is a person that utilizes the software from a support provider perspective. Helpdesk support engineer, that sort of thing. One of your team members.
ReplyDeleteNOT a general end user who submits tickets but rather the person that responds to them.