Your Digital Agency Sucks at Support
When you buy a brand new car you expect to be able to bring it in for maintenance. The same is true for a digital property. The harsh truth is that most digital agencies suck at providing any type of support once they wrap up a project. How would you feel about getting stranded in a new car and having no one to call?
The traditional agency business model relies on billing hourly project work. A high utilization rate and effective billings rate can only be achieved when team members are able to work on projects for long, uninterrupted stretches of time. Support queries are often unplanned and take relatively little time to resolve. They are the nemesis of every project-based organization that does not have a dedicated team to handle these inbound requests.
This leads to client frustrations. They want to have their requests resolved within a reasonable timeframe. Your team gets frustrated too. They often get pulled away from projects they need to be working on. Everybody loses.
Support as a Profit Center
Support should not be a detractor. The only way to set this up within an agency setting is by making it a profit center. This means support in itself should be a revenue stream that covers its own costs, the additional overhead and then some. The erratic nature of support work does not sit well with us, so we set out to create a dedicate support offering that has both:
Predictable workload: Putting out fires sucks. We rather stick to a set cadence and frontload work by doing a bit of planning on a month-to-month basis.
Guaranteed revenue: We can not forgo project work for "maybe" revenue.
We ended up creating a product that we now call "Service & Support", which is provided in a retainer format starting at 100 hours a year. Each month a team member sits down (either over video call or via ticketing system) with our point of contact and scopes the work to be done for that given month. The retainer hours are spread equally throughout the year, so starting at 8 hours a month.
This product offering does not only satisfy the requirements above, but also keeps us in close contact with our clients. By proactively reaching out each month we manage to surface work items which we would otherwise only know about on the day before the client needs the change to be live. We've also noticed an uptick in project-work from these clients, just because we're top of mind.
Instead of having support negatively impact our bottom line and fielding disappointed clients, we transformed support into something that generates meaningful revenue.
Carving Out a Support Team
Creating a new support product helped structuring our work and immediately satisfied a need for our customers. This product has been in existence for more than 4 years with zero customer churn. We hadn't yet solved our division of labor problem; team members who were performing project-based work were still helping doing support. The solution seems obvious: create a new Support Engineer role and transition over all clients. This proved to be more difficult for two reasons:
Realistic utilization rates for Support Engineers are much lower (55-65%) compared to team members performing project-based work (75%+), meaning we had to develop additional revenue sources to make up for the lost revenue.
Support is traditionally an add-on service, making it hard to grow independently from our project-based work. We needed at least two Support Engineers to have some form of continuity.
These two reasons combined made carving out a support team a long process. We've started by trying to increase our yearly Average Revenue Per Customer (ARPC) by pushing our Service Level Agreements and Hosting & Maintenance products. I don’t have the exact numbers, but estimate that we’ve increased ARPC by 30% over two years, making up for the lower utilization rate. We also purposefully started relieving more experienced team members from support duties to reduce costs.
While we previously only offered support services to existing clients, we’ve selectively signed on contracts to grow the amount of support work we perform. We’ve always been cautious about allowing this, but this allowed us to hire a second Support Engineer sooner than if we had only allowed support work via project attrition.
Support That Doesn't Suck
We’ve onboarded our second Support Engineer last quarter and I’ve seen another meaningful difference in the level of service we deliver due to:
Higher level of standardization. We’ve improved our processes allowing for a better customer experience. I personally felt this additional level of refinement was too much of an ask for non-support engineers. The single-responsibility principle of only Support Engineers performing support work allows for this.
Better performance tracking. The team has come up with their own Scorecard KPIs to track performance, which has already shown its usefulness in terms of motivation.
Proactive quality improvements. While our support has been mostly passive in the past, we now proactively identify opportunities for improvement and roll this out across our support clients. This exemplifies our ambition to create a premium offering.
Overall we've managed to achieve what we set out to do, although I'm somewhat embarrassed by the time it took. According to the current timeline I expect the final Service & Support contract to be transitioned this summer, meaning our teams can finally get back to what they do best. Onwards and upwards.