One of the promises of the work in areas like DevOps is to make the flow of knowledge between areas like development, operations, and support easier and quicker. As I said in my blog, Mind the Gap, “Devops is not only the application of agile approaches to operations that have been hugely successful in development organizations. It is also the attempt to bring these organizations together so the agile practices make the gap between them easier to overcome.”
What makes this gap so difficult?
For a lot of us in support, we don’t speak the same language, don’t measure the same outcomes, don’t work in the same rhythm as the rest of the organizations. One of the best examples always comes up when I talk about measures with support and professional services teams together. Professional services teams, almost without exception in my experience, measure their impact on revenue. Support teams, also with rare exceptions, don’t have their contribution to revenue as one of their key measures. The result is a lack of a shared perspective of what is important to measure. Services consultants have to move on to the next revenue-producing client, while support wants these same consultants to stay longer and hand off a perfectly complete implementation.
So how do we build that perspective?
One way to build a perspective across the organization is to create a common language of measures that make sense to both sides. This common language of agreed-upon measures will help both silos understand one another’s actions and deliver the same results. I’d like to suggest two emerging measures for support executives.
|Measure||Description||OCMF category(what’s that?)|
|Support Qualified Lead (SUQL)||A lead that goes to sales or account management where a support team member has determined that a customer or prospect (in the case of a trial customer) is ripe for a cross-sell or upgrade sale.||Business|
|Support Requested Enhancement (SRE)||An enhancement request to a product or service that was surfaced by a customer, support engineer, or data analysis of CRM/knowledge systems and is prioritized and submitted to product management or development||Knowledge/Collaboration|
Why these two measures?
There are three good reasons why these measures make sense:
- They are written in the language of the team that will receive the information. Marketing teams are intimately familiar with different kinds of qualified leads (marketing qualified leads (MQLs), sales qualified leads (SQLs)) and product managers and sustaining engineers are used to getting lots of enhancements.
- These measures will get the organization to communicate faster and provide higher quality information across from support to these other silos because both have built-in quality checks. All the stakeholders can see whether support qualified leads convert to true sales opportunities at the same rate or better than those from another source (like a marketing campaign or outside sales organization) or whether more support requested enhancements are scheduled in new software releases than enhancements from an open community.
- Both emphasize the value that support is adding to the lead or enhancement process. In both cases, support has reviewed and prioritized certain information that is important to the product and sales processes.
I believe that these two emerging measures can provide an excellent foundation to build faster, more effective transfer of knowledge between support and other parts of the organization.
Join the OCMF movement today
We also have a well-established LinkedIn group that talks specifically about measures for support executives.