Home / Supporting Customers, Not Just Modules

Supporting Customers, Not Just Modules

Dries recently blogged about our recent change to “support everything Drupal 6” and I’d like to expand on the details a bit. It’s one of many changes we’re likely to make as we learn how to shape our offerings to better serve the Drupal end-user and consulting communities.

The "big aha!" is that we’re supporting Drupal customers vs Drupal modules.

What exactly is “support”?

Acquia Support helps subscribers configure and fix their Drupal 6 (and above, when later versions are released) sites on a wide variety of platforms. We provide basic "how to" and "break/fix" support for the Drupal core, themes, and contributed and custom modules.

We offer various subscription levels with differing response times, access channels and priorities. Problem resolution, however, is identical across all subscription levels.

RAQs (Recently Asked Questions)

Let me answer a number of specific questions people have asked directly or on various posts. Some of these same questions can be found in our FAQ and we’ll soon update it with any new questions presented here.

What do we do when we find a bug?

* We may fix the bug or advise the customer on how to fix it, depending on the customer's urgency and situation.
* We may contact a contributed module's maintainer and work with them to get it resolved.
* We guarantee response times but, like most support organizations, we cannot guarantee resolutions or resolution times. We do guarantee that we'll do what we can to help customers be successful.

Do we contribute fixes back to the community?

Yes, we are individually and collectively active members of the Drupal community in that regard. Fixing a bug is good for us all. When we fix a bug on behalf of a customer we submit it back to the relevant module maintainer. It remains the maintainer's decision to commit the fix or not. If so, great. If not, the customer will need to maintain that fix on their own through subsequent upgrades.

How do we support custom or modified modules?

We’ll do our best to resolve issues in custom or modified modules like any other module. If the module was created by a third-party then we may want to involve the author for assistance should the need arise (with the customer’s permission). If the problem is too broad in scope to handle as a normal support issue then we’ll recommend resolving it through Professional Services or through a development Partner.

How do we support custom themes?

Same as above.

What about issues involving hosting providers?

We’re more than willing to help diagnose issues arising in hosted environments. We’ve been successful in helping customers overcome permissions and basic configuration issues. Most hosting providers are helpful and willing to work through issues. At the same time, Acquia is not the hosting provider’s customer and there may be limitations in a hosting capabilities or policies that only the customer can pursue if changes are needed.

What’s “Advisory Support”?

Our Professional and Enterprise subscriptions come with a fixed number of “Advisory Support” hours which customers can use to answer questions that generally start with, “What’s the best way to...?”.

Customers use their advisory support hours in a number of ways. Most ask for recommendations on which module(s) to use to achieve certain desired functionality. Some ask for best practice advice on handling deployments, upgrades, or in top level site planning.

In general, Advisory Support is a phone or online discussion that we might augment with some prepared material suitable to the situation. Advisory Support does not encompass doing site specific analysis nor does it result in any site-specific deliverables. It’s a “tell” and not “do” type of support.

Where does Advisory Support end and Professional Services begin?

Customers looking for a specific deliverable such as a site architecture plan, custom coding, performance analysis, a managed upgrade, testing, etc. are looking for help from our Professional Services team.

Diagnosing a support issue may lead to the discovery of problems sufficient in scope that they can only be resolved in the context of a project. Here's a guideline I provided to the Support team when we were asked to recently render an opinion on some custom code.

* Generally speaking, when we move from looking an installation's collection of modules to looking at code, we're in the fuzzy zone between Support and Professional Services.
* If we're looking at code to determine if a standard module can replace the custom code and provide the same functionality, then I'd say we're nearer to the Support side.
* Analyzing the quality and structure of the code in question puts us nearer to the PS side.
* Anything more than 10-15 minutes of looking at modified modules or custom code crosses the border into PS-land ...

Acquia may participate in part or in whole on certain Professional Service projects, whether doing the work ourselves, connecting members of our Partner Program (qualified Drupal shops) with customers in need of help, or providing project management.

Do you have a knowledge base or other online references?

We have some good documentation, forums, and have posted a number of technical articles but we do not yet have a subscriber knowledge base. Building a well structured knowledge base tool is underway and those of us in Support are anxious to get it done and start populating it. Once built it will take some time to reach a critical mass of useful content, however we plan to make it available very early in the process.

Behind the decision

I’d like to share a bit about how we arrived at the decision to change the support model. The support offering was initially limited to the Acquia Drupal distribution only because we didn’t initially believe supporting the entire Drupal 6 universe was a viable support model.

It became clear soon after sticking our toe in the Drupal support ocean that supporting a relatively small number of modules was too complicated to sell and it was somewhat impractical. Potential customers raised many questions about how and where we were going to draw the line when diagnosing and resolving issues, especially amongst those who know Drupal well. Since any module can affect practically any other module, what were we going to do when diagnosis led to an issue in an unsupported module? We previously said we’d take it as far as we could and then point the customer to d.o or to other resources. But where does that leave the customer? Some possibilities would be eliminated but the customer's problem would be unresolved. There’s not much value in that and those considering Acquia subscriptions told us so. We took the feedback to heart.

What choices did we have?

We considered broadening our support to the top 100 modules or top 20% of modules as ranked by usage. We debated creating “bands” of modules supported at different price points, and other variations on this theme.

None of these ideas made Acquia’s support offering any simpler to explain and none resolved the fundamental issue: Customers paying for commercial support for any application want to call one vendor and they want the whole configuration supported, not just part of it. They want guaranteed response times and they want to know someone is obligated to pursue a resolution on their behalf. That’s really the essence of commercial support, isn’t it?

When it came down to it ...

We looked more closely at the Drupal support process. The bulk of our time involves holistic diagnosis of the interactions of a site as a whole: all modules, custom code, and themes anyway (duh). In practice, we were going to have deal with the whole configuration to some degree anyway. .

After exhausting ourselves with all this slicing and dicing we finally looked at each other and said, “We can do this. We can support customers running Drupal 6 and above.” (Funnily enough, our tag line from the beginning has been "Commercially Supported Drupal"). It felt right. It makes sense. But is it a viable business model? We think so.

By charging a fair price based on the fact that all customers will use more or less support at different times over their lifetime we can offer everyone the scope of Drupal support they need and want today. It’s the insurance pricing model as some like to refer to it.

Looking ahead

We're thrilled with the universally positive response to our new support model. We're hard at work to make sure we can deliver as promised to customers who choose to take advantage of our services. Customer feedback is vital to our decision making process and I invite you to comment with any questions, issues or concerns.

Next post from KG: The Customer/Acquia/Consultant relationship. Our concrete commitment to the win/win/win. Andrew Riley gets it. I’ll say more next time.

Comments

Posted on by Boris Mann (not verified).

This is a great improvement. It makes the Acquia offering a lot more compelling, *especially* the higher end packages.

I would actually encourage you to potentially add something like a "no nos" list. That is, we recommend AGAINST you using module X. Well, maybe that's the same as saying "use this module instead", which is a bit less negative :P

Posted on by Kent Gale.

Yes, that's an interesting thought. We've had some internal discussions about how we might present certain module metrics in a very objective way such that people could draw their own conclusions about quality, suitability, etc. We don't have anything specific on our roadmap at this point because we're still brainstorming sporadically on various possibilities.

Posted on by Joseph Bachana.

I like that the support plan is evolving to best fit the needs of the customers and the marketplace. This is a welcomed change, since we were concerned about other modules that we (and others) would be building alongside those 'certified' by Acquia.

I still like to think that Acquia will have a certified core build that all Drupal shops (and customers) should be using. Then, your diagnostic support services can get really valuable once everyone is starting from the same place.

Keep up the good work,

Joe Bachana
DPCI
1560 Broadway
New York, NY 10036
http://www.databasepublish.com

Posted on by Kent Gale.

Do you mean a certified build of Drupal core per se, or of a collection of modules such as we have assembled in Acquia Drupal? And what would "certified" need to mean for it to provide you and your customers with the most value?

I ask because different open source projects treat the notion of "certified" in different ways and I'm interested to hear your take on what it could mean for Drupal.

Thanks for the feedback.

Kent