Tag Archives: interruptions

SupportPress In Action

Posted on by
3

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.

Being Sick

Posted on by
Reply

With my iPad and my MacBook I have to say that the classical lines of distinction of “The Workday” have blurred completely away. I find myself doing my best work at 1:30am or 3:30am, or even when inspiration strikes. I think that’s one of the hallmarks of how technology is changing our lives for the better. I don’t have to write a flurry of ideas down to process at some later time when I can do them RIGHT NOW. Then again, my work style is built on speed. Think fast, act fast, do it right the first time.

Even when I’m sick and hacking up a lung, I can create new blogs and assemble rights for users, and thanks to Apple and all the infrastructure I’ve combined around my work life and my private life I can do all of this pretty much from anywhere, even while driving 70MPH (as a passenger, of course! SCANDAL! :))

I think it’s something that the classical structure of business life will eventually have to address. The idea that if you have a salaried employee who is as mobile as I am and as technologically connected as I am, that we can really do our jobs competently from a rest stop as much as we can do it at work desktop. To that end I have to admit that I encourage my coworkers to heed the wisdom of non-blocking/non-interrupt based communications. I no longer really use a telephone and I don’t really value face to face communications. I prefer my communications to be of the type of Email, SMS, or Instant Message. I think these forms of communication are far more respectful than the intrusive nature of blocking/interrupt based forms of communication. Writing me an email means your message was received and understood and will get the attention it deserves, the same with the other non-blocking/non-interrupt forms, such as SMS and IM’ing. If more people would adopt these forms I know I’d be a far happier person.

I think a good portion of why people elect to use the blocking/interrupt model is because they believe there is a value in the personal approach. They are afraid of the non-blocking/non-interrupt forms to lead to alienation and depersonalization. I get enough personal interaction in my life and the last thing I need is “expensive context switches” where my task flow is interrupted by someone calling me on the telephone or knocking on my door. I often wish I could tell these people that I understand their need for human contact, I don’t require it of them myself and would vastly prefer the non-blocking/non-interrupt based communications styles. The only time I want to see someone in the flesh is if something has become an emergency, then fine. But here again, I make an exception that must be tempered – not everything is an emergency. Even when “emergencies” come up seven out of ten times those emergencies aren’t, they’re just wearing the garb of an emergency to provide an excuse to block/interrupt.

I think eventually more professional people will see the wisdom of this and finally understand that in an average workday the time-wasting emergency-based “humanizing” approach is just wasting money and time. This approach is just as good for the sources of these blocking/interrupt based issues as they are for us victims of their blocking/interrupt driven behaviors. By not having to get up, not having to pick up the phone, you save yourself so much time, to say nothing about the clarity of what you want to convey. You just can’t beat the low signal to noise ratio of text over voice.