When I’m on vacation I have lots of free time and so I start coming up with ideas for blogging. The biggest challenge I have is balancing these moments where I have lots of free time and can blog prodigiously versus those times when I am so busy I can’t possibly blog. It’s either feast or famine. There are times when I wish services like Plinky had some sort of tracking ability. I hate the idea of having to keep a list of what Plinky prompts I’ve taken up as blog assignments and which ones I haven’t and the site doesn’t seem to have that as a capacity. Is there anyone out there who would like me to write about specific items maybe? I just blog about what occurs to me or things that are remarkable in my Pocket queue.
I’ve been kicking around several ideas including more work-related blog posts, especially when it comes to getting things accomplished, using our ticket system, and running a help desk in general. I think that will take more planning because I have to tread carefully. Work tends to get rather picky about what I write and share, and there has been heavy drama time in the past and I’d rather not have to deal with that malarkey again if I can help it.
I also have to remind myself now that my blog is all paid and all bottomless. I can share pictures and even video all by myself without having to deal with YouTube or any of that “passing under the eyes of a censor” kind of thing. Then again, I don’t think that recording video would be the best thing – but maybe so – I’ll really have to come up with things worth talking about if I’m going to do that. Unless I open up to Q&A and swing the doors wide open for anonymous Q&A.
So many ideas… thankfully I have a lot of time to plan and put these things in operation, or not. 🙂
Hawthorne
While running my SupportPress system for several months now it dawned on me that the MySQL database that lurks just behind the scenes is collecting quite a bit of accidental detail on my coworkers that use the system. Nothing that would endanger anyones privacy, so quickly put that notion out of your head. What it does do is record the datestamp of when people enter tickets into the system. Generally people enter tickets right after they’ve identified a problem, of if they come to us, we start the ticket as the first thing we do, so again, the initiation of a ticket is in a general sense linked to just after the problem was detected and brought to our attention. For the remainder of this post, I assert that the datestamp on the ticket is when the problem occurred.
So with a middling amount of database skills and analysis under my belt I decided to run some aggregate queries on the data. Here’s what I found:
When I aggregate all the days of the month together and count how many tickets were initiated on which particular days I discover four notable days where things seem to on-average, go haywire: The 1st with 81 tickets, the 6th with 66 tickets, the 12th with 56 tickets, and the 23rd with 79 tickets. What’s really interesting about this dataset are the dates on the opposite side. The least haywire day is the 31st, with 11 tickets then the 28th with 20 tickets and the 3rd with 28 tickets. So now I can say, in general, that the 1st, the 6th, the 12th, and the 23rd are “Days That Suck”. The best day is the 31st.
I ran the same analysis but instead of days of the month, I used hours. In general the mornings are where people seem to have the most problems. 14 tickets at 7am, 201 tickets at 8am. At Noon the tickets drop by a hundred, then from 2pm to 4pm it rises gently but nowhere near the morning values and the afternoon peak comes between 4 and 5pm. After 6? The rush of tickets just stop. People don’t report problems when food is on the line. 🙂
The last analysis I did crossed day and hours together and counted the tickets. This had some interesting data in it, since I was just looking for any notable outliers. Hours and Days where the ticket level was say, more than 20 for that hour. Here’s some of the “Problem Days and Hours”: The 1st of the month at 10am and the 23rd at 10am.
What is to be determined from these really general findings? There are some cursed days at the office apparently. The 1st, the 6th, the 12th and the 23rd are really quite troublesome for people. Mornings are rough but on the 1st and 23rd, at around 10am the shit hits the fan.
SupportPress collects this data for as long as it runs and I’ve no intention of stopping so the further we go the more (or maybe less) pronounced these interesting bits of information will get. Those that work with me that also read my blog might have some insight or they may just find some of this helpful if they have spare vacation days to spend and are looking for some reason to not come into work.
SupportPress At Work
Several months ago I became aware of certain workplace changes that were going to only be a problem if I chose to ignore them instead of doing something about them. There’s always been a part of my job that I’ve been kind of awkwardly ignoring. I lacked any kind of real instrumentation to one of the major aspects of my job, in fact, it’s the part of my job that I regard as being truly central and my “first hat” and that would be the Advancement Services Help Desk. First and foremost I go to work to help people use technology. That I didn’t have any online structure in which this fit has always bothered me. I always rationalized it as “My shop is too small to need such things.” or “It’s too expensive and I can’t prove that the ROI will justify the price.” but all that changed when given a purpose by a workplace change that was coming, and me discovering SupportPress.
SupportPress itself is a WordPress theme for a WordPress.org installation. We already had a hosting company that we had a great relationship with, [iPage](http://www.ipage.com]. It struck me that while we had a site with the host I certainly wasn’t making the most use out of our investment as I could. After a long while I logged into iPage and noticed their SimpleScripts service off their Control Panel. SimpleScripts is an interface to install very popular LAMP-based scripts that add features to a hosted website. Various scripts include WordPress.org, Drupal, and a gaggle of other ones including some eCommerce scripts that I really couldn’t care more about. WordPress.org is the free-to-use DIY version of WordPress.com. WordPress is a wonderful blogging platform and it serves as the bedrock that SupportPress runs on. So setting up the WordPress.org site was exceptionally easy. It was a click and some typing, followed by a few more clicks in SimpleScripts and it was done just like that. A fully featured and functioning blog running on my web host. After that, I looked at SupportPress and discovered that the theme sold for $100. One payment and you get a license to run it on as many blogs as you like. It wasn’t a subscription, just a straight simple sale. After buying the theme from WooThemes I downloaded it in it’s native form, one single ZIP file. I opened up and logged into my WordPress.org blog and navigated to the administration side of the system and right there, as easy as you please is “Install Themes Here” and the preferred option is “Install Theme from ZIP”, which I had exactly! So I uploaded the SupportPress Theme ZIP file to my newly made WordPress.org blog and when I applied the theme and went out to my blog, everything was functioning as promised! Everything! A fully functioning Help Desk Support System was running without any extra tomfoolery. I didn’t need to muck about with source files, fiddle with settings or update anything to get things to work as they should. This software, all of it, from end to end is what writing ELEGANT system code looks like. It works without guff, simply, directly, and elegantly. After that, all I had to do was create user accounts for all my clients, assign a few as “Administrators” like my assistant at work and I was done. I had the entire project from plan to finish in about an hour!
SupportPress has two distinct interfaces. The first interface, the one I use is the “Administration” interface. It very closely resembles the “User” interface but has a lot more options. If I need to perform anything more in-depth I can always call up the WordPress.org administration interface itself (which supersedes the themes administration console, wrapping around it actually) and I’ll show off both interfaces in this blog post. The system is organized on the management of Tickets. A ticket is a self-contained event that requires help from me to my clients. A ticket could be anything from a lost password to a report that a copier is malfunctioning. A ticket in SupportPress has a title, a description, a status, a type, an owner and an assignment. As an administrator I can see every single ticket and manipulate every single ticket. I can change ownership (the client), the assignment (who is to help), the status (which all new tickets start as new), the type which indicates what category the ticket belongs in and I can add comments and attach files, anything that can be done in email, except it’s logged in a database. The best way to describe it is to show it:
SupportPress Administration Screen
SupportPress New Tickets
SupportPress New Ticket
This administration interface is a full-view while the next few screenshots show what the client sees. It is much more direct:
SupportPress User View
The system is a pleasure to use and goes so far as to suggest top-ranked KB articles for clients as well as displaying all the clients tickets and their statuses with two buttons that are clearly marked for starting new tickets. When clients type in a title for a new ticket the system will automatically (while they type!) scan for relevant KB articles and display them. Eventually as the KB becomes more robust users will start to discover fixes in the KB on their own and in some situations actually be able to help themselves. When a user submits a ticket, the administrators get an email notification and the ticket resides in the system as “New” and assigned to “Anybody”. Any of the administrators can log in to the SupportPress system and look at these tickets and assign them either to themselves or other administrators.
When an administrator makes a change to a ticket, that change is sent as an email notice to the client. Everything you do to a ticket ends up being sent in an email every time you submit a change. So if I see a ticket, assign it to myself, set it’s status to “Open” and change it’s type to “question”, for example, the user will get an email showing what category was changed, the old value, and a graphical arrow pointing to the new value. If there is a comment or attached file, the client is sent an email indicating as such with the comment sent along in email so the client can read the update.
Tickets go from New to Open, then either to Waiting or Pending, then to Resolved. Sometimes tickets go into “Researching”, “Recurring”, or “Limbo”. The last status, “Limbo” are for those tickets where the situation is beyond waiting, but we still want it to hang around for some reason.
If all of this wasn’t exactly what I was after, the cherry on top is that this theme comes mobile-ready as well. It renders beautifully on an iPhone and iPad, and technically any mobile device as well but those are the only two devices I have to test the site with. Technically anyone can have an account on the site and anyone can submit tickets. I really like how clients are insulated from each other and only see community information in the KB. For admins, it’s all open and available. I really like how that’s structured.
Sometimes clients ignore that we now have SupportPress and elect to get our attention other ways. If they email us, I simply copy the email into a new SupportPress ticket, and set the owner to the person who sent the email. I love that I can create a new ticket on behalf of a client as if they sent it! Any other method of communication that isn’t SupportPress now gets a ticket for each event. If it’s a knock on our door, a ticket. If it’s a phone call, a ticket. If it’s an iChat, a ticket. Everything I do for a client gets a ticket and that way not only do I instantly document everything but the client can see everything about their tickets in one convenient place anytime they wish. They can go into old tickets and see who responded, when, and what they did about the issue. I’ve also started to use the standard blogging features of the WordPress.org site that still exist. SupportPress shuffles that off to the “Blog” menu item. If ever there is something I wish to record, I just send the SupportPress blog an email with the contents of whatever it is I want to record and it ends up being placed in the Blog section. I like to think of that as my “Captains Log” which lets me write odds and ends about the function of my office in one central place. If ever I need to refer back to it, search on it, or print something off of it, there it is. One handy place.
The hosting was inexpensive, the installation of WordPress.org was free and took about seven minutes. The cost of SupportPress was $100 and took about five minutes to install. It took about thirty minutes to set up all the clients and after that we were on the ground running. So for $100 and less than an hour I went from having no help desk infrastructure to having a damn nice one. Nobody has complained and so I count that as votes of approval. Some of my clients have started to adopt SupportPress directly and others have not. I don’t care since I stop people before they get going when it comes to in-your-face interactions to tell them that I first have to create a ticket for them.
I couldn’t imagine going back to the way things were. This is so much more convenient and safe for me in general. It keeps everyone feeling good, feeling honest, and provides a huge amount of CYA if ever a problem of help desk performance should ever pop up. Each ticket contains date and duration stamps which clearly display how each issue was handled. There is no he-said or she-said, there is only the ticket and what it says. Objective, clear, and rational. Again, I couldn’t imagine running a help desk any other way.
SupportPress In Action
My first week with SupportPress has been magnificent. It was just in time as well, as we are looking down the barrel of a bunch of employee location movements which always requires lots of tickets and tracking because there are just so many discrete pieces to work with whenever someone moves from their established location to a new one, even if it’s temporary.
It’s also been a series of lessons when it comes to introducing new technology to regular folk. The adoption rate was much higher than I hoped for, as people were actually jockeying for “first ticket” so that felt really good. I’d estimate about fifteen percent of the staff have moved their communications channel to the help desk completely over to the new SupportPress system, while the rest have yet to break their old ways.
The old ways we still will respect. Having this new help desk system has given me moments of decision to make and learn from. Do I force people to only use the SupportPress system? Do I turn the office into a BOFH zone by forcing my clients to fold their entire communications structure into a ticket? Turns out I rejected that choice and elected to endure the steeper path of being, in what really turns out to be a human bridge, for my clients. So when someone drops by, someone calls, someone emails, or someone iChats us up, each time it calls for a ticket. SupportPress in this regard is really great, as we can create tickets on behalf of our clients and fill in all the details as if they penned the tickets themselves.
Another choice was one of statistics and performance. Now that the SupportPress system is providing us with ticket numbers and categories as well as ticket ages, the data is ripe for analysis, categorization, and the temptation to turn all of these raw numbers into performance metrics is very strong. This, as it turns out, is just another BOFH move that I simply cannot take. I refuse to use the raw data to measure any kind of performance metric – there is more to my life, to my assistants life than how many tickets we land or how old the tickets get before we tend to them. Here is a central tenet of mine, this system is meant to help only. It will never be used as a dashboard, it will never be turned into a yoke, or a bridle. The same way I rejected the before-mentioned BOFH move of forcing tickets out of clients, this is somewhat like the other side of the argument. The reasoning behind it is that I want people to use this resource. I want my employees (singular notwithstanding) to not fear that they will be lined up against some artificial measuring stick and slotted. I refuse to have First Trumpet, Second Trumpet, and Screwup Trumpet chairs in my orchestra.
There are other things that have occurred to me but I have rejected out of hand, brought about by SupportPress. I have considered and rejected a “Zero Ticket Friday” policy as fundamentally broken. What is so special about Friday that all tickets should be closed? If I institute that policy and some tickets are stuck in the waiting queue, do I penalize people for it? If you start making accommodations for things like “tickets can languish in the waiting queue forever” then what the hell is the point of the first move on this policy? Eventually it’s the self-defeating policies like these that create the bullshit of “It’s Friday, lets push all the tickets into the waiting queue.” It’s just dumb. So we aren’t doing it.
One thing that has come of SupportPress that we’ve noticed is that some of our clients have reacted less-than-happily about the sheer flow of SupportPress notification emails. The system sends an email when any ticket moves or changes, so clients could have at least two tickets (a start and an end) or up to double-digits especially if there are a lot of phase changes and clarification messages flowing back and forth. I personally don’t have a problem with notification floods as I am rather OCD about managing my email. I’ve written before on how I manage my Inbox – that any email has four potential destinations after they have been read. An incoming message can be stored in Evernote, sent to Toodledo, adapted and stored in SupportPress or outright deleted. Yes, I still use Toodledo, but I use it in conjunction with SupportPress. Some tasks, such as weekly reminders and such really fit better with Toodledo than SupportPress. Nobody really cares that much about getting constant notifications or trackability about daily, weekly, or even monthly tasks that I work on. Much of the regular things I do at work are “Andy does it, so we don’t have to worry about it anymore.” and so everything gets done and people can move on. That’s really helps illustrate the core features of SupportPress. SupportPress is designed to capture the discrete, non-repeating, highly interruptive traffic that any competent Help Desk must endure. There have been a lot of whitepapers written on the economy of interruptions surrounding Help Desk environments so going into it here would just be needlessly duplicative. The only really important thing to state about interruptions is that they are a necessary evil. People have to stop us to get help, it’s the nature of the beast.
SupportPress shines brightest when it comes to creating an abstraction layer between clients and the Help Desk. I like to think of the system providing a certain amount of slip between ticket arrival and first contact. In this way, SupportPress slays the interruption dragon that besets us. Instead of people electing to visit us or call us, which are the most interruptive, they can issue a ticket. We are notified that a ticket has arrived and that fact can be temporarily slipped in time so that we can conclude whatever function we are executing without having to endure the most dreaded thing of all, a context switch. Much like computers, interrupts and context switching is the number one gross consumer of time. These interrupts and context switches also threaten our quality of work. We can switch quickly but regaining traction once we’ve switched back to what we were thinking about before can be sometimes a maddeningly slippery proposition. I can’t count the number of times that interrupts and context switches have caused me lost time when dealing with a columnar data procedure such as checking items off of a long list. Where was I? Am I doing everything right? Why do I have this nagging doubt that I’m missing something? It’s this that I wish people would understand, and why when we ask people to issue their problems via ticket, why it’s so helpful to us.
So then we revisit an earlier point I had made, that I have elected to not force people to create tickets only. While this is true in spirit, I dearly wish people would on-their-own elect to use the less interruptive technologies available to them. The best thing for anyone to do would be to issue a SupportPress ticket outright, but if not that outright, then email or instant message also works well, because those technologies also include a modicum of temporal slipping that we really crave when we are knee-deep in some elaborate procedure. So while I refuse to force people to do a certain thing, I respectfully request that they do what they’ll do a certain way. Then it comes to how best to encourage people do change their course? First you have to let them know what it is that you’d like them to do, in a way, this blog entry may help with that as I suspect some of my coworkers read my blog and maybe they’ll notice the hint. One thing that can be done is rewarding people for using the ticket system by prioritizing those people who issued tickets with more force than we would otherwise pursue an incoming interrupt and context switch. It isn’t outright sabotage, but it does show that there is a preference and it’s in everyones best interest to respect us with the grace of a non-interrupt, and hence, non-context switching request. We’re driven to help and that is our passion and our purpose, but there is a best way to do it and for me at least, SupportPress is it.
So how much did it take for implementing this solution? We already have an iPage hosting account, wmichalumni.com, and frankly any host worth their salt would be just as good. I just like iPage because they are professional, no-nonsense, and cost-efficient. Any host can (and should) allow you to set up a free copy of WordPress.org. WordPress.org is an open source and free bit of software that creates a WordPress.com blog on a host that either you own or rent. The infrastructure of WordPress is actually perfect for what we are trying to do. The fact that it’s free is just a cherry on top. Installation of WordPress.org, at least on iPage is remarkably simple. It takes about 5 clicks and some little typing or usernames and passwords and preferences and the host creates a perfectly functioning WordPress.org instance for you. The theme, which is what SupportPress really is comes as a ZIP file for $100. Once you buy it, and then upload the zip file to your new WordPress.org site, everything else is pretty much a freefall into implementation. Falling down a flight of stairs is more complicated than installing SupportPress. Once the system is going, creating users is a snap, then introducing them is equally as easy, and before you know it, you’re up and running and your total outlay for the project was $100 for the theme and whatever you are paying your host.
So, then that begs the question of why we don’t self-host. I chose to not self-host because there is a field of tar which would ruin usability. iPage has unlimited bandwidth, unlimited storage, and since we are already paying for it to do other things, it’s arguably ‘free’ to do our SupportPress infrastructure. I don’t have to endure needless bureaucracy and it’s available anywhere and anytime without me having to muck about with VPN technology or anything else. It’s not that what I am avoiding is that onerous, but this way is far far simpler and is much more satisfying to me in that the path that I took got it done. From zero to implementation with nobody to argue with, nobody to ask, nobody to cajole, and nobody peeking over my shoulder.
I think that any Help Desk, especially one in academia, but really this extends to any other industry as well could really benefit from SupportPress. I like to reward products that please me and do their jobs well. When I find a product, like SupportPress, I flog it for all it’s worth. My only regret with SupportPress is that I didn’t have this technology 10 years ago. I am blessed to have it now and I plan on continuing to use it and I plan on taking it with me wherever I roam in the future. If anyone has any questions about anything I’ve written here, you know where to get ahold of me. I welcome questions on this, SupportPress is that good.
SupportPress
I just rolled SupportPress out to the rank and file at work. Or at least I thought I did. My day was going so well, so smoothly. I got my introduction email with graphics sent out (or so I thought) and I got all the invites shipped out as well. Everything was going just peachy – until I looked at the sent mail and noticed that when I sent the message by copying all the discrete addresses that only the first address took. So I didn’t send out any message at all!
To really get a grasp on how irritating this was, I couldn’t send a message to the LDAP alias that expands out to all the people I work with, the address is dar-staff@wmich.edu. The SMTP server at WMU was rejecting it out of hand. Turns out I figured out why – it was the screenshot graphics. That system they have rejects mail with pictures. So I had no choice but to copy down all the addresses from our Wiki and do it manually. Turns out when you copy that kind of information into Sparrow, it only looks at the first address and ignores everything else. It was my thinking that it would see the commas and figure out I was copying in 48 addresses. No, just one really long address.
When I noticed this, all I had was my iPhone and I was having lunch with Scott. I was cursing Webmail Plus and the LDAP directory for placing artificial limits on email and so I figured I could get the list of addresses and paste them into my iPhone and use the Mail app in my iPhone to do the heavy lifting. Turns out it suffered the same mental block, treating the addresses I pasted in as one giant address. So after lunch was over I was in my car trying to tap and copy one address at a time in. This is another bad idea because if you tap and don’t hold the iPhone thinks you want to email to just that one person and so dumps the draft you were working on and starts a new draft with an empty email. The forwarded bit with all the text and graphics? Lost. Three times lost. I was successful in the end, shipping my intro email out to all my coworkers despite all the technology surrounding me meant to make things easier.
Alls well that ends well, so we’re up online with SupportPress and I have to say that I am very happily surprised with what I see. Clients see a very simple version of the site and it’s compatible with every browser, every computer, including iPhone and iPad to boot! Now that I’ve let the genie out of the bottle it will be very interesting to see how it is received. There has been lots to say on that topic before, and in another post, a more private one, I’ll go further into the nitty gritty details.
So despite technological hurdles, I was able to get my automated help desk system off the ground and show it off to people. Monday is going to be a rip-roaring day, indeed!