Tag Archives: host

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.

American Dining

Posted on by
Reply

American dining has a cultural crisis looming on the horizon. Partially it is based on our weak-kneed economy which pushes many of these establishments to the edge of failure, so far away from profitability as to be sorrowfully laughable. Beyond the weak economy, American restaurants have a distinct series of problems that they really have to face.

The first issue with the American dining experience that strikes me immediately is that many restaurants that attempt to create a valuable dining atmosphere by dimming the house lights. The idea runs that if the lights are subdued then people will see it as romantic and attach those warm feelings to the place where they dine. In America, this is a problem because what is seen as good if you take it only so far is seen as much better if you take it way too far. Many restauranteurs have said time and time again that people eat first with their eyes. To see food is the first step in creating a lasting impression on your customers. In America the lights are so dim that it is nearly impossible for someone with 20/20 vision to clearly read 10-point text that is being held in their own hands. The lighting in these establishments is dimmed to the point of unpleasantness. You can’t really see who you are dining with, the food looks muddy and dull and the entire experience is one of tragedy. As an example of this, I just dined at an establishment, which shall remain nameless, in which the house lighting was so poor that I needed my smartphone’s illumination to read text on a card that I had in my own hands. When the food was delivered the lighting was barely enough to identify what was on my plate. It was the first step in a very unsatisfying evening. So, what’s the advice that I have for restaurant hosts? Turn up your house lights. If you are hiding in the dark then we can conclude one of these situations may be true:

  • The food is ugly, and so it’s dark to protect your mistakes.
  • The host is ugly, and so it’s dark to protect your feelings.
  • The guests are ugly, and so it’s dark to protect other guests feelings.
  • The decor in the establishment is ugly, and so it’s dark to cover the decorating transgressions.

The upshot is, when it’s too dark to read words on paper, when your guests are using their phones to find their food, then there is either something wrong with ugly or you are just trying too hard to amplify romance and have landed directly in the dimly lit antechamber of hell, a place that is referred to as heck. Many American restaurants have embraced heck to such passionate levels as to take the breath away. This is a shame, because in many of these establishments the only way you can navigate is with echolocation, so not having the sound of your breath bouncing off obstacles is a true peril for the diner.

The next issue has to do with communication. In this regard, there is way too much communication in the American dining experience. The procedure is always like running the gauntlet, the host is often nervous and like Mrs. Peacock they suffer from a pressure of speech. They arrive tableside and disgorge in an effluent of chatter. You cannot engage in a conversation because you are constantly being interrupted by a curious host who, wrapped up in good intentions is obsessed with making sure that everything is running smoothly. This has infantilized American diners. We can’t operate our dining experience without a chatty, clucking, obsessive hen buzzing the table every 2 minutes. Even here American restauranteurs make tragic mistakes, especially when it comes to effusive apologies. The protestations of sorrow from some hosts fly so fast and so thick that you often times wish they would just get a gun, load every chamber, point it at their heads and pull the trigger. If you are so sorry, then die for it. If you aren’t, then shut up. Some hosts just cannot leave well enough alone. That’s why in America dining is an olympic speed sport. How fast can you choke down the food? You have to because to endure dining is running a verbal gauntlet and since you cannot have a cogent conversation with a solid train of thought while you dine, it’s more advantageous to skip real conversation and switch to smalltalk which entertains nobody. All that is left is the food. In the dark. With perhaps an ugly host, you can’t be sure.

What is to be done about this problem? American restauranteurs need to take a page from the French way of dining. Collect the order, then silently orbit the dining room, spotting low beverages, spotting soiled napkins, that sort of thing. Be conscientious enough to spot silently and silently tend to what needs tending. If the diners wish to engage in an interruptive exchange they should be the ones to initiate contact. A fussing clucking chattery mother hen would have alienated every french diner in the restaurant. There is something here that bears to be understood. Keep your chattery teeth to yourself.

Then we get to the food, which begs the ancillary point of pricing. If you are going to cast yourself as destination dining, produce output that is worthy of your aim. Here’s an example – I just dined on a plate of chicken, green beans, and potatoes in a butter sauce for $18.00. There were three small strips of chicken, I would classify the cut as “chicken strips”. There was a small woman’s palmful of green beans and three 1-ounce scoops of potatoes. There was about two ounces of sauce. This was not a meal. This was 40% of a meal. To say I felt robbed was an understatement. Four diners, three with an appetizer course, 4 mains, and 1 dessert split three ways – I declined the appetizers as none of them suited me and I didn’t find the dessert choices appealing enough to partake. The table bill came to $128.00, we were two couples, split that bill in half and with tax and a standard tip of 15% my outlay for dinner was $76.00. What did I get for that money? I got very little. Scott got slightly more, but had to bark the cook into cooking his duck breast as the standard fare is apparently rare duck, which might as well be raw chicken for a health aspect to it. It boggles the mind. So, when you are busy charging your customers outrageous prices for fussy cuisine which does not match value for price, tread carefully when complaining to said customers about how little business you get to walk in the doors because of the prices.

What should restauranteurs do? I heartily suggest ripping a page out of the Gordon Ramsay playbook: Keep your food local, fresh, simply cooked, for fair prices and you will be a success. Deviate from that plan even in one spot, like obnoxious pricing for example, and you will alienate your customers.

So here I sit. I’ve paid a restaurant bill of $76 dollars and I’m going to go to bed hungry. I will never go back to that restaurant again, once bitten twice shy. As I was discussing it with Scott, this is the cost of the lesson to decline such dining experiences in the future. I just don’t have the wherewithal to financially support such endeavors. I can only hope that some people who run restaurants read this and take these bits of advice to heart. Turn on the lights, shut the hell up, and stop charging an arm and a leg for what amounts to being a pittance.