Cloud Computing Ziff Davis Enterprise Ziff Davis Enterprise
Advertisement
Advertisement
Wednesday, November 25, 2009 10:19 AM/EST

Handling Deadbeat Cloud Computing Customers

EmptyPockets.jpg
Over dinner last night in Manhattan, my friend Christian Renaud recounted a horror story in mobility: His iPhone service was shut off while he was traveling in Spain and Portugal. The reason wasn't because he didn't pay his bill, but rather he had exceeded his data limit - not once, but twice.

Renaud is the CEO of Palisade Systems, a provider of data loss prevention software and managed services. He was in Europe for a series of meetings with researchers and security collaboration partners. Like many executives, he needs constant contact with his company and clients, which is why he bought the international voice and data package from AT&T.

Now, the service gives him up to 5MB of data transactions per month. He received a warning from AT&T stating that he was about to exceed his limit and they were on the verge of shutting off his service. Rather than risk being disconnected, he upped the service plan to 25MB per month. A week later, he exceeded that limit, but this time AT&T simply shut down his service. Not even offering to pay the bill made a difference.

The incident got us talking over our margaritas and Mexican dishes about the consequences to solution providers if their customers either exceed their service limits or fail to pay their bills for cloud-based services. What if a customer doesn't pay their monthly bill? Do you shut off their service or issue a warning? Do you throttle access to resources, or do you extend service until a payment is received?

It's a legitimate issue. Solution providers and cloud computing vendors are already discovering one of the sticking points in cloud sales is customers' fear about having their data trapped in one service provider. One of the problems with many cloud-based applications is the inability to easily migrate data between service providers. Just ask anyone who's tried migrating to Salesforce.com from a competing CRM application. Failing to pay for service could land a customer in doubly hot water as not only can't they migrate to a new service, but they won't have access to the online resource.

It's a sticky issue that I haven't seen much discussion on. There's just a presumption that cloud computing is more efficient and cost-effective than on-premises solutions. But an on-premises solution has the benefit of paying for something (hardware or software) once and never having to fear losing access to applications and data (at least assuming the systems work without service and maintenance agreements).

So what considerations need to be made by cloud computing solution providers and their vendors for customers that either won't or can't pay their invoices? Can their data be held as collateral (hostage) until payment is made? Are there legal issues for denying customer access to data and applications that impede their business operations? And can terms of service and service-level agreements effectively cover such situations?

TrackBack

TrackBack

http://blogs.channelinsider.com/cgi-bin/mte/mt-tb.cgi/18602

Comments (4)

Doug Stein :

The real issue is that SaaS contracts need to enforce relationships (e.g. look more like marriages or mergers) and not merely transactions (e.g. one-night-stands or asset purchases).

Unfortunately, for all the talk about clients and vendors getting closer together, they still tend to think arms-length. Worse, they view the relationship as untrusted or one-sided.

In the end, the problem isn't the technology - it's that the technology needs to be matched with the business relationship (and wrapped with the right contracts to clarify and enforce it). If you want an arms-length relationship with the counterparty, you probably don't want a SaaS deal. If you want a strategic partner, you probable *do* want a SaaS deal.

AT&T (the example given) doesn't really want relationships - it really wants to latch on and bleed you through services. It only cares about relationships in the aggregate (focusing on metrics like churn and lifetime customer value).

Companies tend to have the strongest relationships with other companies who are similar in scale. Contrary to screwball romantic comedies, the CEO doesn't marry the girl in the typing pool often. That's why the traditional big vendors build a VAR channel - to bridge the social divide. It's also why channel development is so important to the emerging SaaS vendors. Even if the "product/service" scale up and down effortlessly, the sales, contracting, and support processes don't!

david childs :

Bit like a bank account really.
Overdraw and you get a nasty letter +a penalty charge on your account.
Like letter from Doug above it needs to be set out from the start in plain english,stating what is given,for what price and if you exceed what will happen.

It makes sense. But I guess this requires a certain amount of education on the part of the solution provider. I mean, how comfortable am I, the buyer, knowing that one or two false steps and I could be locked out of access to my data?

I think Doug had it right: cloud services is more like a partnership with the customer, and that partnership requires consistency in delivery on expectations. The solution provider delivers an application; the customer needs to make payments on time.

It's somewhat similar to the payment system of electricity and water utlities. So that makes me wonder whether the government could regulate some level of access to data even if an account is in default. Utilities, by law, just can shut down service to people because they haven't paid their bills; they must go through a process to avoid any hardship or the creation of a public health situation. Could the same be said of cloud computing, where shutting down customer access to data could cost jobs?

Joe :

Good question but ultimately it comes down to how comfortable is the enterprise with handing over their data to 3rd party vendors.With other environmental barriers( I.E. hackers and political instability)other factors need to be adressed as well.

Post a Comment

 
 
Advertisement
Advertisement