The Maturity of Hosting

The Maturity of Hosting
by Richard Manulkin

Ok.. let’s talk about the cloud. Before we get started, I’m going to use some terms interchangeably – Hosting or Hosted and The Cloud. The way these things are defined, The Cloud is a subset of hosting. For the purposes of this article, all Cloud is hosting, but not all hosting is The Cloud. In general, I’ll use the terms interchangeably. If I need to draw a distinction, I’ll be clear about it.

As indicated by the title of this article, my thesis is that Hosting is a mature, stable and viable option for many, many things. Before I get into more detail, you should know that hosting has been around for a very long time. Depending on how loosely you want to define it, it’s been around for thousands of years. But even in the narrower technological context we are going to discuss, it certainly has been around for over 100 years.

Let me also caveat by saying many of my examples, and much of the character of this discussion is based on the call center industry. Although the general theme here extends throughout the business spectrum, I’m really talking about what we do as an industry.

I see all sorts of articles, emails, weblogs and podcasts explaining how you can take advantage of “The Cloud”, or how you can use “The Cloud” to your advantage, or how to use “The Cloud” for something… I’m waiting for “how to use The Cloud to hide from enemy aircraft”.  Hey – writers need subject matter, and you can exploit any new terminology for a few thousand words many, many times.

Now, I’m not knocking these writers. From a granular level, there are so many ways to think about using hosting that you may not have thought of, that you can glean important nuggets of information from many of the articles I just made fun of.

However, if you understand the concept of hosting at its core, it’s really not a mystery at all.

In spite of the details you may gather from specific hosting articles, let me explain to you what I hope you glean from this article.

When looking at a new technology that can be provided as both premise-based and hosted, most feature checklists have a box for, well, hosted or premise-based. That needs to go away. Forget the methodology – instead look at it granularly like you would between any other systems. For example you might have the following features

1) Requires redundant power (yes/no)
2) Requires highly skilled labor on staff (yes/no)
3) Requires specific hardware (yes/no)
4) Capital outlay ($x.yz) ($a.bx)
5) MRC ($ ($
6) TCO

You’ll likely have many different options to fill a need. My point is “hosted or not” should not be a deciding factor. A product’s reputation, total cost, feature set etc. should be all that matters. The specifics of methodology employed to meet your needs is as irrelevant as the color of the box that holds the software.

If you think about it, this should not be a huge revelation. If I was the first person ever to create a hosted ACD, and I came to you and said “hey, you don’t need an in-house ACD – use my hosted version”, you’d look at my reputation – which would be non-existent – and say “come back in a few years”. A few years later, I may have a few customers. You might then say “your prices are too high”. After a few more years, I might make the final cut.

The above situation is not hypothetical. I’ve been working with IVR since 1989 (yes, that’s 2.7 billion years), and hosted call center platforms since 1998.

IVR was an easier sale as a hosted solution. Although many premise based systems had some rudimentary call routing, anything as simple as the ability to take a voice capture and then have a function to play it back for transcribers was not an available feature. Then, as premise based solutions added more features for IVR the model shifted a bit. In a way, it’s the reverse of the situation with ACDs, Dialers, and other call center services – CRM, order processing, etc.

As in call center infrastructure in general, there are inherent differences between hosted IVR and premise based IVR. For each application, looking at the entire picture from implementation time, total cost, reliability, internal resource needs, etc. should be the deciding factor, not simply premise based or hosted.

Writing and maintaining complex IVR systems is not as simple as some might make it sound. Over the years, I recall sitting in sales meetings with operational and development folk, and after some discussion, the development folk would get all smug (you could just SEE it in their eyes) and either say right there in the meeting (or sometimes afterwards out of my earshot) that what we were going to provide was something they could easily accomplish. We’d lose that sale due to the idea that it could be done in house.

More often than not, in cases where the IVR was a critical part of the business, we’d be called back in for another talk within a few months. From my perspective, and that of my development staff, creating voice response programs is not a big deal. Other technical folk – as indicated above – felt the same way. The difference is that we’ve done this kind of stuff for years, and those other guys just saw what we were doing as simple programming.

Why did the “do it yourself” guys fail? For the same reason IVR frontrunners had issues back in the late ‘80s. They looked at IVR as solving a rather simple programming task. We have a much more sophisticated view of it now. Also, IVR was our core competency. For the “others”, it was just another task to complete. They really didn’t have time to spend going through and making the interface changes, tweaks and other interface requirements while being busy doing other, more critical programming tasks.

At the same time, with our experience, our core competency, we’d built libraries of functions for all sorts of IVR tasks that, over the years, were honed until essentially perfected. We know how to properly phrase audio. We know how to break down menus more efficiently. And, making small changes are very easy for us, where for newbies it may require more time.

Here’s a very simple example of why hosted providers have an advantage over a premise based solution being run by a wise programmer. If I need audio recorded, I can get it done the same day and have it up. Not only have I honed my own voice to be useful, I have relationships with voice talent that I can call up and say “hey, get this done for me”. These kinds of things take time to develop and learn. Now, there is much more to being able to run a hosted IVR company, but I think you’re getting the idea in general.

I’ve provided the above pre-ramble to bring us to a very important point – something you really need to think about and keep in the front of your mind when considering options for your technology.

Hosting is a viable option when you have a business NEED that is not your business – your core competency.

I think the IVR example above is a clear demonstration. Folks NEEDED some IVR. They could have hired a full time staff of IVR programmers, but that would have been a waste. They tried doing it themselves, but for the most part they failed, or if they succeeded, it was much harder and more expensive than they thought. Why? Core competency!

Let me reiterate:

Hosting is a viable option when you have a business NEED that is not your business – your core competency.

Let’s talk about a fundamental need that you don’t have any clue about – electrical power. I’m going to make an assumption that –in normal business mode – all of your electrical power is provided by a power company. In theory, you could provide your own power.

(Let me stop here and say that many of you have backup generators. Hopefully you test them weekly, and test your transfer switches and UPS systems often… otherwise when your power goes out, your backups are as useful as a spare tire that’s flat)

So – electrical power is a hosted solution.

Here’s a place to make an aside and discuss a difference between “hosting” and “the cloud”. In “the cloud”, you’re never quite sure where your data is. When you do a Google search, I can promise you that there are a set of specific machines that are taking care of doing the searching. If you are using Google Mail, there are specific hard drives that hold your data. I can also safely say that nobody knows what machines or drives hold that information, and the specific hardware may change between searches or overnight, etc. To me, that’s a “cloud”… the stuff is “somewhere”.

If you want to talk about hosting that’s not “cloud based”, it would be something like if you had someone hosting your email, and they had 2 machines sitting in a data center that were mirrored and then backed up to a specific device or set of devices. If you wanted to find your data, you could point to one or two machines and say “there it is”.

Some companies have an f: drive or a g: drive where you store data that you want backed up. These are your company’s file servers, and to you, they’re a “cloud”. To your IT department, they’re likely a series of machines. They are “hosting” your stuff…but are not quite “the cloud”.

Other folk may have other definitions, but for the moment let’s just assume those other folk are wrong.

So, back to power generation.

Intrinsically, there is no particular reason you can’t be the primary supplier for your own power. However, I can name plenty of reasons why a hosted solution makes more sense. My guess is that it would cost much more than having a utility. You’d probably want 3 generators capable of handling your entire load – plus more. You’d need special contracts with fuel suppliers, you’d probably need all sorts of permits, electricians and electrical engineers on staff, spare transformers, EPA inspections, high-voltage experts, etc.

It’s certainly much easier, much cheaper, and more reliable to simply pay a company to supply you with your electrical power.

Likewise, you could supply your own water. Some homes do with wells and pumps. My guess is you’d rather just have a valve opened from the water utility and go from there.
And no matter how sophisticated you may be, all of you use telecom and long distance providers to some extent.

To be clear, BPO Call Centers are hosting facilities, right? Your clients have a business need – to answer a phone and make sales or help with customer service – but their core business is not that.

Many BPO Call Centers have to contend with clients who want to bring their agents “in-house”. In some cases, it may make sense for the client to do this. In other cases, it’s hard to say, and in other cases it might be a huge mistake for the client to go in house.

When a client is deciding to bring something in-house, they (hopefully) weigh the pros and cons of each method. The problem with this balancing method is the old saying “we don’t know what we don’t know”. So if they go in – house, very quickly they may realize things they weren’t aware of, and suddenly they have some core business problems trying to run something they don’t know how to. To go back to our previous example, what could go wrong if you decided to generate your own power? This example, of course, is a much bigger leap than simply having folk answer the phone and try to sell a product. But ultimately the difference is quantitative, not qualitative.

You don’t host your own money – you use a bank. You – in general – don’t host your own delivery – you use USPS or UPS, etc. If you have a fleet of cars, you probably don’t maintain them, although you may insure them. You probably hire an outside cleaning service for your office.

Some of you may be thinking – “ok, this is getting to be a bit ridiculous”. I disagree. These are indeed all things your company outsources. Mail, electricity, water, cleaning, building maintenance…the point is that all “hosting” – in essence – is outsourcing. Clearly, outsourcing is a mature method for helping businesses meet needs that are not their core competencies.

You can call it “the cloud” or “hosting”, but it simply means that someone else is doing something for you that you need done but that isn’t something you are the best at doing.

The biggest difference between, say, having an electrical utility supply power and having a hosted provider handle your e-mail is that of time, familiarity and specialization. 20 years ago, people first started having their own email servers. After a while, hosted versions came out, such as Hotmail and Gmail. Then some folk started hosting, oh, Microsoft Exchange. Some IT departments became so frustrated dealing with their own Exchange servers that they migrated corporate mail to the hosted Exchange servers. Exchange hosters became more and more specialized until at this point it’s probably easier and cheaper to go ‘out-of-house’ for Exchange.

We did! My company certainly has the expertise to manage an Exchange server. We certainly need one for our business! But it’s taken considerable work off our IT staff to have it hosted. Now, that staff can stay focused on maintaining and improving our cloud infrastructure, which is our core business.

Time to get back to specifics. For this article, talking about hosting means talking about hosting technology for call centers. Specific examples are of course hosting ACD‘s and Dialers. Other options these days include, for example, hosting CRM, Lead Management and Order Processing.

As with most technology, improvements are happening at a very brisk pace. Technology is getting cheaper, more feature rich, more reliable, more user friendly… but at the same time, truly understanding and maintaining the technology becomes a more and more tightly focused skill set. It is not my place here to expound the virtues of hosting over premise based solutions. Aside from being self-serving, it’s really not the point.

The point, again, is that within the context of call centers, the specific fact that a product is hosted vs. premise based really shouldn’t be viewed as a choice on a checklist. Simply looking at the pros and cons of any solution is the more useful approach. There will always be a few common “check marks” between hosted vs. premise based, but look at those as individual choices anyway.

Truly sophisticated, carrier grade hosting options are there, and have been for about a decade. Because these products are able to constantly evolve in a more organic and continuous fashion than premise based solutions, they have had a much easier time to catch up with the features and reliability of legacy systems. Ten years is a very long time in technology.

Choosing a solution one requires the same diligence regardless of the location of hardware. You check out the feature set, the reputation, ease of use, quality and availability of support.

In the coming months and years, you’ll still be seeing more literature about how to use”The Cloud” to your advantage. Obviously, I like that from a business perspective. On the other hand, there will always be arguments for having your systems on your premise, so the choice is yours.

The bottom line is you’ve been using hosted services for years, and many of you are providing them, so making the switch where you haven’t before isn’t a paradigm shaking decision. It’s a choice you’ve made many times, often without even realizing it.

~ by Darren Prine on October 11, 2011.

2 Responses to “The Maturity of Hosting”

  1. Great blog! Is your theme custom made or did you download it from somewhere?
    A design like yours with a few simple adjustements would really
    make my blog jump out. Please let me know where you got your theme.
    Appreciate it

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: