Get More Specific: avoid the slippery slope of generic support services
As a web dev agency, your goal is to provide your clients with long-lasting success, that means providing constant maintenance is necessary. Nobody said it was easy, though. On one end, it costs the client extra money, and on your end it requires a lot of time and effort. On top of that, the value of constant maintenance is hard to quantify. Predicting what’s going to need your attention is like trying to predict the winning lotto numbers: you certainly know what the numbers could be, but there’s no way to tell in which order they’ll fall or in which combination.
Since defining which services will be needed can be difficult, many agencies just charge a generic, cover-all retainer in exchange for being there when needed. The problem with these is that they open up a whole new set of problems, ones that often lead to disappointed clients, stressed out team members, and ultimately to profit losses. One seemingly harmless request for support can quickly turn into an avalanche that buries your team under, so changing your approach to charging retainers can end up being a lifesaver.
Getting more specific, that is, charging more specific retainers, helps you keep your footing, maintaining your team’s balance on the side of what could be a very slick mountainside. Aside from clearing the fog away from what it is you’re actually doing, it helps manage client expectations and make life easier for both sides. Here’s how:
The issues with generic retainers(and why specific ones are better)
By offering a simple, cover-all retainer– you know, “the pay me this quarterly and we’ll support take of you”–type deal, most companies think they are making things simpler on both sides. After all, a “one size fits all” mentality often implies simplicity. But this isn’t socks; it’s web dev support. The reality is that these generic retainers are fraught with danger, and often cause a lot of trouble. For example:
If you haven’t clearly defined your services and are only operating under a generic support retainer, then it’s inevitable that you’ll get sucked into discussions with your client about what it is you actually do. “Does the retainer cover this”? “What costs extra”? “Why are things different this time around”, etc. This is an inefficient waste of time in most respects. Clearly laying things out in the beginning will help you avoid most of the “how does my support package work?” kind of questions.
When you receive payment under the promise to support the client in all matters, you are now obliged to support them on everything! Those are some lofty expectations put on your shoulders. If you somehow don’t manage to follow through on any requests, you’ve now ticked them off when you could have avoided placing those expectations on yourself from the get go. If you haven’t clearly defined your service, then you haven’t managed client expectations at all.
When you don’t know how many or how big the support requests will be, you open yourself up to issues in planning. You will have many other clients all expecting the same level of service. Nobody wants to be put on the back burner because you prioritized someone else, so you can’t just brush off your other projects for the sake of an urgent request, but you also can’t brush off an urgent request for the sake of other projects!
The slippery slope of support requests
The problem with even seemingly innocuous requests such as:
Is that they are rarely just that. Think of them as the myth of the one-hour flight. Sure, the flight takes an hour, but what about packing, getting to the airport, going through security, and getting your bag on the other end?
All of these issues can quickly snowball. First you’ve wasted a bunch of valuable time answering questions, and then your client is upset because they expected something more. Now you’ve got to move team members away from their current project where they were probably in the zone and get them to work on something new. Your team is ticked off and so are your clients. Now what about unforeseeable variable like multiple requests, picky clients, or downtime?
Support is easy in theory; difficult in practice
One way to combat the chaos of dealing with support issues often employed by teams is setting aside specific periods during the workday or week to handle support. Great in theory; difficult in practice. It takes a ton of discipline to take time out of important projects to handle support requests. Taking time out of working routinely also doesn’t solve the underlying issue: the variance that is inherent in supporting a client’s website. Just because you have set aside time doesn’t mean the client (or the client’s issues for that matter) will always fall in that frame.
Offering more distinct support services will serve to clearly define what you do, manage client expectations, and even make you a bit of extra money. It’s like a submenu for your clients to work with, so that you both know exactly what’s coming. You’ll never be able to totally predict everything, but it will make it a lot easier.