How to sell Drupal support with value
Selling support is not so easy. Mostly you end up with agreements such as getting paid only if there’s a support request. If you want to provide reliable support with a well-defined response time, you need to allocate resources constantly, and that's why you need to get paid separately for the response time. The value for your customer is clearly that an experienced user, who also knows details of the project, is available whenever he or she is needed. A support contract with a well-defined response time keeps at least some of the project team members available, so the knowledge doesn’t get away.
Another service you can sell in terms of your support contracts is dedicated development time. We provide these "retainers" for agile projects that have an ongoing adoption to their changing environment. We provide X hours of development time on fixed days of the week. For example: 3 hours of a developer's time on Monday, Wednesday and Friday. This agreement will make it possible to plan the development for both you, the Drupal shop, and your client. You’ll know when your developers need to work on the support project and they don't have to jump between projects whenever the client has a feature request. In our experience, this leads to a much more productive and healthy relationship with your customer, as it eliminates the long wait until somebody pays attention to the features, and there’s no discussion about scheduling unpaid development time. Sure, these time slots need to be paid for, and your client needs to adhere to these slots. You could charge your client less if there wasn’t any work to do. But please consider that, on the one hand, you have expenses for your staff and missing revenue on the other, as you could have assigned your developers to other projects that were paid.
Another value a customer gets with your support services is security and sustainability. Only projects that get updated continuously are sustainable and extensible in the long term. Security update SLAs are important, as there could be another highly critical security issue that needs to be fixed within 4 hours. That’s impossible if you don't automate at least your security updates.
While selling update services isn’t easy, it does get easier if you focus on the value you provide for your client. Always analyze what will or could happen if you’re not available in time for critical updates; if you can't answer a call for a very important question; or what happens if the server needs to scale as traffic has recently increased a lot? Then there’s no time to get a quote, so that's why availability is of such value to an online business built with Drupal – somebody will be there for your client when he needs you.
Quite often, we’re asked if it’s better to build a dedicated support team or have your developers to do support. There are vastly many pros and cons, so I’ll just mention 3 for each.
Dedicated support team: pros
- Developers can stay focused and don't need to jump between projects
- There’s really always somebody available to answer requests
- You can provide "one face to the customer", as resources don't need to switch around
Dedicated support team: cons
- It's expensive if you only have a few small-budget projects
- The support team doesn’t have the project knowledge that developers have
- Technical support team members may get bored if all they do is answer questions
Support by developers: pros
- The project-related knowledge is available for efficient support
- Developers see what happens to their projects and how clients use it
- You can grow your support revenue in a lean way, without requiring new team members
Support by developers: cons
- They’re not always trained – or willing – to talk to customers
- Negative impact on other projects if developers have to switch to support
- Hard to plan development and support resources
What is your experience with providing Drupal support services? You are welcome to share your experience in the comments.