Drupal support business - What your clients really need

Drupal Support

Since my talk at Drupalcon Barcelona about a recurring revenue for Drupal shops I’ve had several discussions with other agencies about how to grow a professional and reliable Drupal support business. In this blog post I’d like to share with you the things I've learned. This is the first of a three-part series on Drupal support business.

What your clients really need

Your clients invest a lot of money in the development of their Drupal app. And like any investment, a Drupal app needs to be maintained. A client that earns money with the app you built will most likely need the following services:

  • Hosting
  • Bug fixing
  • User support
  • Update support

Hosting is the foundation of an online business. Without hosting, a client can’t even use the other services. Hosting is a good service if you want to increase recurring revenue and scale. But it's not the core business of a Drupal development shop. Particularly for small companies, growing a dedicated business unit for hosting can be very risky, because operating a hosting/server platform requires special know-how, and at the beginning these resources are usually in short supply. We recommend reselling the services of a professional Drupal hosting provider. You can scale up with your hosting partner, provide reliable support for the infrastructure and grow your recurring revenue at the same time with sales commissions. Partnering with a hosting provider will keep you and your team focused on what they know best: developing Drupal applications.

Bug fixing is something most clients cannot understand. "Why are there bugs if you developed the application properly?" is something we hear quite often. From a customer perspective, this question is obvious. When he buys something, it should work; and if not, the developer needs to fix it – for free. Of course this depends on the agreement and how you control the expectations of your client. Sure, you should always fix bugs that you produced, for free. But what if the client decided to use Drupal, and it’s a bug in Drupal or one of the contrib modules? You know the answer: analyzing the origin of the bug takes up most of the time, usually far more time than fixing the bug itself. So correct me if I'm wrong, but if the customer pays for all bugs in Drupal but not for bugs the developers produced, who pays for the analysis time? That's exactly the point, and here’s what we do: If you work with clear requirements in your project and consider the right things during your project specification, you can use those requirements to rate a bug in a very objective way (user stories for instance). If there’s no initial requirement that’s broken, it's not a bug but a new feature request: the customer has to pay extra to implement the new feature. If there’s a bug related to a requirement, we fix it for free – including the analysis time – as it was our fault. If there’s a bug, but it’s related to a Drupal module or Drupal core, we have an agreement that we share – 50/50 – the time and costs for both the analysis and the bug fix.

User support is needed mostly for complex applications. User support ensures that a user can continue to work with the application you've built with Drupal. The user support is provided by a ticket system or a hotline to help users quickly.

Update support keeps the Drupal and contrib code extensible and the investment sustainable. Applying security updates is a must-have for every professional Drupal site. If you don't apply updates continuously, the risk of broken sites increases exponentially with the size of the delta between the current code base and the code base of the latest version. Remember Drupalgeddon, where you had to update all sites within 4 hours? That's where update automation comes into play, as the critical update could be released while everyone’s asleep! Protecting a site around the clock is something that should be covered by a serious SLA. The update time will depend on the details of that SLA and on the importance of the Drupal app for the business (e.g. 1 hour, 4 hours, 8 hours).

Those four services can be included in your support agreements. Providing or reselling these services will help you to increase recurring revenue for your Drupal shop and to serve your customers with everything they need. That's why we call our agreements "operation support".

In the next post in this series, I’ll explain how to sell support contracts by presenting the value of your service.