SLAyers 'R Us

November 17, 2010

Mergers are a true test of a company’s mettle – the stress involved with working an integration process with the need to continue to drive the business is almost overwhelming at times (CBNO!). The activity that is going on around me at present is awe inspiring – everybody is pitching in to make this work. It is great to see that we are making it happen – just rewards for all the effort expended.

Mergers also mean change. And I don’t just refer to the fact that we are welcoming new colleagues to the SoftLayer team. I am also referring to the fact that we are changing how we do business. We are bringing together two different organizations and combining the best components of each to drive the most value for our customers.

This inevitably means that customers are going to see some change in how they interact with SoftLayer. For example, the portal is going to morph into something that is much better than what SoftLayer or the Planet were doing separately and new product additions will arrive by combining The Planet offers with SoftLayer’s automated (automagic from now on) implementation and service delivery. We think these things are big wins for the existing and new customers.

A tangible example that I can talk about now (we need time to get portals and new products to market!) revolves around SLAs. The new SLAs will work to the benefit of existing Softlayer and the Planet customers as well as new customers.

The SoftLayer SLA is improved upon by changing the SLA for hardware and hardware upgrades. The old world considered a 4 hour promise before credits started to accumulate; the new world moves that to 2 hours. In addition, service outage credits start accumulating after 30 minutes of down time versus 43 minutes under the old 99.9% uptime guarantee.

The Planet SLA is improved upon by introducing a hardware SLA across the board versus just for customers of a managed services product. In addition to the 100% uptime promise that we are keeping, we have erased the need for a customer to raise a ticket before the clock starts ticking. Once there is a problem, we start the clock running.

At the end of the day, the reason we have SLAs in place is simple. Service credits on next month’s invoice are of less value to you than the fact that the SLA is driving SoftLayer to deliver on a service promise. If it’s broke, we are going to fix it. Think of the service credits as a bonus – the real value is getting your stuff up and running again.

-Steven

Comments

November 25th, 2010 at 8:19am

>> real value is getting your stuff up and running again

The real value is if our stuff stays up and running, you should not be thinking of anything less. If any SL business change is likely to take a TP customer's server down even for 5 minutes, don't do it. Otherwise, you don't have the mettle, and your tp customers will be all gone.

>> Once there is a problem, we start the clock running.
We just had a server non responsive for two days. Thankfully we just shipped over the customers on it to rackspace two days before this. But we never got any notification from TP/SL

December 1st, 2010 at 10:02pm

Steven, this is a pretty well written blog post but doesn't really hit the point. The point is that SLA credits to the customer are worth much less than the negative impact of the outage that triggered them. The wrap-up of your blog post doesn't really solidify that in a customer's view.

Customers want to see that you are now better prepared to handle outages, failures and other variances. The potential of getting a $9.50 credit on their next month's invoice isn't a real benefit.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.

Comments

November 25th, 2010 at 8:19am

>> real value is getting your stuff up and running again

The real value is if our stuff stays up and running, you should not be thinking of anything less. If any SL business change is likely to take a TP customer's server down even for 5 minutes, don't do it. Otherwise, you don't have the mettle, and your tp customers will be all gone.

>> Once there is a problem, we start the clock running.
We just had a server non responsive for two days. Thankfully we just shipped over the customers on it to rackspace two days before this. But we never got any notification from TP/SL

December 1st, 2010 at 10:02pm

Steven, this is a pretty well written blog post but doesn't really hit the point. The point is that SLA credits to the customer are worth much less than the negative impact of the outage that triggered them. The wrap-up of your blog post doesn't really solidify that in a customer's view.

Customers want to see that you are now better prepared to handle outages, failures and other variances. The potential of getting a $9.50 credit on their next month's invoice isn't a real benefit.

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.