Most recently, the term “cloud” is becoming ever-popular, stemming from “cloud computing.” Also heard often is “thin client.” Microsoft even had a commercial out with the phrase “to the cloud” as the focal point.

This kind of language jargon makes me feel like a stranger in my own career field. It bypasses the true purpose of something, and instead labels it as some dumbed-down, kid-friendly, whiz-bang term that means nothing at face value.

It may sound cool, but it reeks of corporate nomenclature. It’s one thing to use a word that sounds intelligent (as I just did with “nomenclature,” which I had to look up by the way), but entirely another to use words/phrases just because they are catchy or idiot-proof.

We’ve esssentially bastardized the English language with all this excess noise from common words with entirely different (perhaps temporary) meanings. It’s like we’re marketing the English language.

The technology has even birthed the cultural phenomenon of Twitter – short bursts of messages and status updates made for easy consumption and widespread adoption.

That’s great, and all, but I want to say more! Why has technology limited what I can say, or how I express myself?

If our forefathers were able to see the world in 2011, they may be impressed that we can communicate with anyone in the world in a matter of seconds from devices as small as our hands, but that the easiest way to do so only allows 160 characters. This is progress?

Why should a technology’s limitations force everyone to adapt to that world? To a world of limited expression? Why isn’t anyone inventing a better SMS?

What subscription? How much? Who set it to auto-renew?

I typically leave auto-renew off on just about every service I use. The so-called “convenience” is just a gimmick by companies to have some sort of assurance of payment on a repeat basis. Most times I forget what services are set to auto-renew, and then suddenly I am charged for something I haven’t even considered renewing.

I think it’s a shady business practice disguised as a convenience to the customer.

This particular auto-renew was for a magazine subscription – who are one of the worst offenders of shady business practices, by the way.

You can imagine my shock when I saw that it was for a subscription that I started through Amazon.com. I expect more from Amazon, but I have a feeling they don’t have control over some aspects of this, since it is a third-party magazine (ESPN “The Magazine”).

I immediately went into my Amazon account and changed the auto-renew settings to “Off,” then cancelled my ESPN subscription (I wasn’t planning on renewing anyway).

Notice, also, that it was renewed two months prior to last year’s date, with no warning or notice prior to charging my credit card.

Just a warning to those using Amazon for magazine subscriptions. Make sure auto-renew is turned off, to avoid surprises.

To continue with my tech support wishlist for clients, here are some more requests from the perspective of the technical support representative.

Leave your emotion at the door

Don’t bring emotion into technical support requests. Technical support reps do not know you, nor do they care for your well-being. Their goal is to resolve your technical problem as quickly as possible, and move onto the next person’s problem. They thrive on fixing problems, not being an emotional outlet for you. Becoming angry, emotional, or condescending only slows down the process of reaching a resolution to your problem.

This is not a deeply personal relationship between you and the technical support rep. Showing emotion is not going to make the technical support rep feel bad or sympathetic to your feelings. Support reps are not going to hold your hand, and tell you, “I’m so sorry this is happening. Everything is going to be alright.” Or, “You are a wonderful person and your troubles make me very upset, so I am going to get to the bottom of this because I care very much about you.”

Support reps are not there for emotional support – only technical support!

I’m sorry – it’s a cold, emotion-less relationship, but if you give us the information we need, we’ll be your best friend. If not, expect hassles. Period.

Details, details, details

I can’t over-state how important details are, especially when dealing with technical issues.

When submitting a support request, pretend like you’re talking to an alien or young child – you have to start from the beginning. Take a step back and provide as many details as possible. It may seem repetitive and mundane to you since you’re involved in the process, but technical support reps are not involved in only your processes.

Technical support representatives work from a detached, outside, emotionless seat. No offense to you and your product/service, but we only care about resolving your issue as quickly and efficiently as possible. We don’t have time for back-and-forth, repetitive correspondence – every minute wasted is another minute that could be used to help someone else who has provided more information.

That being said, technical support reps only care about the following things:

1. The ability to replicate your issue. Think tangible issue – a point of failure, demonstrated, physically seen, or able to be reproduced.
2. The technical details that could possibly be causing the issue. Think program logic (not your logic!), and how the application actually works (under the hood).

We intend to fix the technical problem, not the corresponding real-world action (even though the former usually leads to the latter). We don’t care that “Susie can’t complete the process,” only about what’s technically stopping her, and for that we need #1 above made crystal clear.

Don’t show the end result only

Repeatedly showing a technical support rep the end result won’t help them discover what went wrong during the process. It’s great that you’ve noticed a problem with the end result, but we can’t tell you what went wrong until we go through the whole process (again, requires #1 above).

For this we need as many details as possible about the process – every step/action you took. Again, support is an investigative resource, not a crystal ball.

It really comes down to #1 – the ability to replicate your issue. Without this, we are in the dark, and your support request will take much longer to resolve.

I’m looking for a good Windows FTP client, but have yet to land on any.

I use Windows at work, as well as home, but I am preferably a Mac user. Unfortunately it’s often easier to conduct my work on a PC, due to the nature of it (web development), where I need access to a particular browser for testing (Internet Explorer).

I’ve tried FileZilla and WinSCP, but neither have the maturity and finesse I’d expect. I run into weird glitches, annoying bugs, and many other things that make me less productive. My FTP client should not stand in my way of getting work done, but on Windows it often does.

I am used to polished, strong Mac applications, like Panic Transmit. Mac applications seem to pride themselves on usability, stability, and quality. I could say the same for iPhone/iPad apps versus Android.

I guess this post is mainly out of frustration, but I would hope there’s a decent, reliable FTP client for Windows that doesn’t keep getting in my way.

“That may be a work-around, but it’s not a solution.”

As a support rep, my goal is to get clients back up and running as quickly as possible. Whereas I can’t immediately fix every bug that presents itself in the time it takes to correspond with someone, I can offer work-arounds that achieve the same result, and allow users to get back on with their day, while the bug is reported to the appropriate person, or delegated amongst other priorities.

Technical support is not here to give you immediate solutions – it’s here to listen to your problem, and offer alternatives until the real problem is fixed. It’s kind of like therapy. Your psychologist does not have all the answers for you, but she’s there to listen to your problems and help you sort through them.

Often a bug or problem is discovered, and noted by the support representative. Clients expect it to be completely resolved the next time the support representative checks in with them.

This is faulty thinking. The support rep is there to take note of the issue, and offer the best possible alternative until the main issue is resolved. The support rep can’t stop and immediately attend to every little issue that comes in – they’d never get any real work done, such as improving the product or service from a larger scope – you know, what brings in money – aka, “running a business.”

Whereas a user may feel their issue should be the most important issue for the company – that’s never the case. The company has it’s own priorities, and has to effectively manage issues from all clients, and prioritize each.

Yes, the bug may cause you temporary frustration every time you come across it, but you should rest assured that the company will eventually fix it, if it becomes a priority enough that it’s affecting many users, and not just yourself.

If the company doesn’t fix it, and it continues to cause you undue frustration, you have a right to find a better product. I’m not condoning neglect or ignorance on the part of the company – I’m just saying that it may not be a priority yet for the company, and losing a single customer is not going to cause the company’s demise.

No product or service is perfect.

But support can be as helpful as possible, and one way to be helpful is to offer the user some way to achieve what they want to do. It may not be the most elegant, but it’s better than nothing.

Related

• Support an investigative resource; not a crystal ball
• Tech support requests: tangible vs. intangible

Despite this setback, this doesn’t change how I feel about Dreamhost, nor do I regret switching to Media Temple. It’s just an incident – it can happen to any web hosting provider at any time.

Never the less, I’m inclined to consider the larger picture here – about web hosting companies in general.

Refunds for time lost

Often “incidents” occur with servers and shared hosting – I get that. But sometimes they last days, not just hours. Why is there no offer of a refund for all time that my sites were down?

If your cable or mobile phone service is down for days, you’d probably get some sort of credit applied to your account – at least, any smart person would inquire about that. With web hosting, sites can go down here and there, and often last as long as necessary to fix the problem, but I never hear of any sort of credit being applied to customers.

This seems kind of shady to me.

It’s one thing to have potential revenue-generating sites completely inaccessible, and another thing to still be charged for the inadequate service.

Redirect down sites to a backup host

My next gripe is the fact that we still deal with “site outages,” in general. In today’s technically-advanced world, why isn’t there a simple way to redirect sites that are not responding? I realize there could be a bunch of different things that cause a site to “not respond,” but there should be some way to detect all of these things, and gracefully redirect a site that is not responding to either another domain entirely (where users could have alternate content ready), or at least a proper error message from the hosting company themselves, such as:

Hi, sorry about this! This site is slow to respond, or not responding at all. It’s possible something technical has gone wrong, and the hosting administrator is certainly investigating this now. In the mean-time, please view this alternate site which should help answer some of your basic questions.

You get the idea. Heck, even if it redirected to a Google hosted site – at least users would know that would rarely ever go down.

I think it’s wise, in this internet-pulsing economy for site owners to have multiple hosting providers, which forms a sort of “escalation plan,” in case one site goes down – the next one would pick it up.

No single hosting provider can ever provide the 100% up-time that site owners yearn for, but having a multiple-host fail-safe plan could be the closest thing to it.

As a support rep, I am often asked why I do not have an immediate resolution, or “matter-of-fact” answer to any question presented by the particular client.

I often hear statements such as:

“Well, you’re the support rep – you tell me why this is not working.”

My approach with any support issue is to investigate. This is done by asking the client direct questions related to their problem, or their specific setup. In order to even begin troubleshooting the problem, I need basic questions answered, such as:

1. What were you doing to cause the problem?
2. What do you expect the software to do in that situation?

I then need to gauge responses to these questions by asking myself:

1. Is the client misunderstanding something?
2. Is this how the software is supposed to behave?

The answers to these two questions help me decide whether the problem is actually a problem, or simply a misunderstanding.

This approach can throw people off – as they expect support reps to know every aspect of an application or process, in response to any possible problems that comes up.

I’ll be the first to admit – I don’t have all of the answers. In fact, I don’t have most of the answers. What I have is the ability to investigate issues, and find the answers.

When working on a software application, or anything involving a group of contributors, each person is usually more adept at certain functions or sections of the application. However, support requests often require us to cross over into other areas that we may not have worked on directly, but are still capable of investigating.

Clients don’t like to explain everything – they just want a solution now.

Unfortunately, I must perform a thorough investigation before any troubleshooting or “fixes” can be made.

Support is an investigative resource, not a crystal ball.

Why not show me lower-case letters when caps-lock is off?

This is not a major deal, but sometimes I want to see what the lower-case letter looks like, while considering things like aesthetics and legibility.

When handling tech support issues, there are usually two types of issues: tangible and intangible.

Tangible issues are real, physical things that are noticeable and, without question, broken. Examples are bugs that display error messages, or a glitch that can be demonstrated or physically seen. Tangible issues are relatively easy to trace since they typically have a point of failure (such as a file and line number where the program failed to execute, or other indisputable evidence that something is indeed broken).

Intangible issues are vague, unproven, and often susceptible to external environmental variables. Most support issues will be intangible. An example intangible issue is, “the program seems slow.” Intangible issues are much harder to trace since there is no point of failure, and are often claimed by incompetent, impatient, or paranoid users, which questions the entire validity of the issue in the first place.

Other examples of intangible issues:

“Can you make sure this feature works? I have a feeling it does not.” This, or they performed some test that doesn’t really prove the feature is broken, but vaguely demonstrates the users paranoia, impatience, or lack of understanding.

When handling support issues, it’s important to remember that it’s a support queue, not a quality assurance queue. You fix what’s broken. You don’t go looking for issues just because you have a “hunch” that something could be wrong.

Support representatives have to work with absolutes – tangible issues. The more time spent hunting down issues that may not even exist is time wasted from making the product better.