The launch of Red Hat Enterprise Linux 5 is an exciting time for the Red Hat support teams worldwide. We’ve been training the Red Hat team and our support partners over the last few months and finally we get to put all the classroom and lab-based training into action as we begin to support our customers’ use of the platform in production.
The launch is doubly important for us as we’re taking the opportunity to revamp many aspects of our support practices, policies and service level definitions based upon input received from our customers. This represents the first set of improvements toward our vision to create a service delivery model that is firmly rooted in open source principles and values; the same principles and values that have made the development model so compelling for our customers.
When you connect the dots on the hundreds of customer conversations we have at service delivery reviews, sales calls, postmortem meetings etc., it’s clear that our customers want to experience a support service that is transparent, that is collaborative across engineers, customers and vendors, and that allows knowledge to be shared readily. With these principles in mind, we’ve been taking a hard look at how we offer and deliver support and we’ve found some areas for improvement.
Take the principle of transparency for example. Today, if you look at the Scope of Coverage definition for Red Hat Enterprise Linux 4 (the legalese for what we do and don’t support), it’s fairly complex. See here. Who would know that the scope of coverage for the installation of Red Hat Enterprise Linux 4 is defined by nine bullet items and anything not mentioned within that definition is considered outside the contractual scope of what we support? And we’re not unique: this is the way our industry has defined support terms from the beginning. All too often the Scope of Coverage is used as a defensive measure, and this can be understandably frustrating for our customers attempting to obtain support. So, to coincide with the release of Red Hat Enterprise Linux 5, we’re blowing away all of this complexity and being simple and transparent about what we will and won’t support. In essence our new Scope of Coverage is, “if we ship it, we support it.” We’ve reduced the multiple screens and literally hundreds of detailed bulleted items down to a few crisp statements.
Similarly, we want to be transparent in how to contact us–be it to pat us on the back, smack us across the head or offer other words of advice and encouragement. So we’ve posted the email address, office phone and mobile phone of every member of the Red Hat support management team worldwide . We look forward to the real-time interactions!
Also at launch time, we’ll be vastly improving the response times associated with support via the web. In fact, we’re removing any difference in response times based upon how our customers choose to contact us. We built our service level definitions on the belief that a customer with a critical support request would prefer to contact us by phone and that support via the web would be limited to non-mission critical items. It doesn’t take a rocket scientist to realize that this is no longer what our customers want or expect. Our customers want to be able to interact with us by anytime, anywhere, anyhow. So to that end, we’re bringing SLA equivalence across all modes of contact. Freedom of choice is a core principle in the Open Source world.
As for delivering a support service that is collaborative in nature, we hear consistently from customers that they worry about finger pointing between vendors that make up their production environment; where everyone feels a sense of responsibility but no one is taking overall accountability for the issue. Over the last couple of years, we’ve worked with our vendor partners to develop cooperative support relationships. Many times, because we’re the OS vendor, we act as the glue between multiple vendors and we coordinate the overall resolution efforts from multiple vendors. We’ve decided to capitalize on this core competence and announce our intention to further develop our point-to-point vendor relationships into a Cooperative Resolution Center. The purpose of the center will be to implement lab infrastructure for testing and problem reproduction, supported by technical and managerial processes that make the collaboration between multiple vendors more effective and efficient. And ultimately to coordinate the support activities in a way that brings transparency to the joint end customer. So far the response from our customers and our vendor partners has been very positive to our activities in this area.
This is some of what we’re announcing this week, and it marks just the first steps in the journey that we believe will offer a fundamentally unique support experience to our customers. In future blogs, we’ll detail more of the changes we’re implementing based upon the customer feedback we receive.