Many thanks to Anirban Maiti for suggesting to revisit this topic.
Every support organization has its technical experts. They know more than others. They can take one look at a complicated case and quickly identify the issue. They often have a line of people waiting for their advice. They unerringly remember an obscure feature from version 2.3. They are the go-to people for escalations. They have cultivated personal contacts in Engineering that can answer questions outside the regular protocols.
What should the savvy support executive do with the experts? My suggestion is to create a Backline team, with a clear mission to serve as the technical conscience of the support organization, with responsibilities that go much beyond saving the day on escalations, and are much more proactive.
The Backline team has four main responsibilities, two reactive (the first two on the list) and two proactive (the last two, and I would argue the more important ones):
- Serve as an internal help desk to the rest of support. The idea is to prevent escalations, to maximize the ability of the support engineers to take issues to resolution, and to increase the skills of the team. The Backliners respond to questions posed to them but also offer help proactively to the owners of cases that are not progressing.
- Manage the Sustaining Engineering channel by prioritizing bugs and requests and managing resolution targets.
- Own support readiness from a technical perspective. The Backliners are the first adopters and train the rest of the team (or serve as SMEs to instructional designers) on new products. They also own the quality of the knowledge base (even in a KCS model where everyone plays).
- Orchestrate customer feedback on the product. Using big data analysis techniques as well as old-fashioned deep dives into case data, Backliners identify root causes for customer issues and champion opportunities to improve the product, beyond merely fixing bugs.
Naturally, the Backline team is involved in customer escalations since tough issues often land in its lap — but it should not be just the escalation team. Indeed, it’s best to specialize other support engineers to handle escalations and allow the Backliners to pursue their proactive mission.
Also, although Backliners are always senior support engineers, not all senior engineers should be Backlines. Backline engineers need to want to help others while getting less personal glory, they need to be great multitaskers, and they need the presence and chops to be the voice of support. Not every senior engineer can do that.
Do you have a Backline team? How does it work for you?
After a successful inaugural run this summer, the Great Support Websites workshop is back this fall, for five 2-hour sessions on November 29, 30, and December 1, 6, 7.
The Great Support Websites workshop is your opportunity to learn about best practices for support websites, study the winners of ASP’s Ten Best Support Web Sites contest, and get a personalized review of your website. We will even give you a choice between a group review, for maximum exposure, and a 1:1 session, for more confidential feedback.
The workshop is conveniently scheduled in short sessions so you can continue with your real job (and the sessions are recorded so you can easily catch up if you have to miss a couple).
Sign up now to get your free makeover. Special pricing is available if you want to bring multiple team members.
The FT Word
The FT Word is a free monthly newsletter with support management tips. To subscribe, click here. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers.
to the September 2016 issue of the FT Word. Topics for this month:
FT Works in the News
Cross-post alert: Segmenting customers for success
Natero published a post I wrote on how to segment for customer success. If you think that ARR segmenting is the only way to go, you will find other ideas that may work better for you, and for your customers.
Time to start a book club?
Back-to-school (and back to budgeting for 2017!) is a great time to start a book club with your support team. May I suggest The Art of Support, the complete guide to managing customer success and support organizations, from strategy to staffing models, to selecting tools? It is available in book-club packs for your convenience and sure to elevate the thinking and morale of your team.
Curious about something? Send me your suggestions for topics — or add one in the comments — and your name will appear in future newsletters.
650 559 9826
About FT Works
FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com.
To request a subscription, click here. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.
Back to Newsletter Archive
If you think that calculating ROI for knowledge management or self-service is hard, try assigning a value to a customer success program!
Since customer success is usually an either/or proposition, where all customers (or all customers above a certain size) get attention, it is very difficult to prove, quantitatively, that customer success programs make a difference. Here are some alternative approaches:
- Just say no to ROI analyses. Having a customer success program of some kind is pretty much mandatory and its success can be measured, but not through a standard ROI analysis. A good place to start would be to see that churn is decreasing over time.
- Does more customer success mean more success? For instance, if you add a monthly check-in step, do you see more renewals, less churn, more expansion revenue? Then you have a good indication that the monthly check-in adds value.
- Do you see lost opportunities due to a lack of a coherent customer success program? For instance, is a large chunk of support requests related to training? Are you surprised by unexpected contract terminations? Do you and your team spend a lot of time managing escalations? In each case, you can cost-justify a customer success program by quantifying the savings.
Have you tried to compute the ROI of your customer success program? What did you find?