What is Backline and what should it do?

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?

Tagged under:

4 Comments

  • Anirban Maiti Reply

    Thank you Francoise for including this topic. I can’t wait to hear what others think about this.

    • ft-admin Reply

      thank you for the suggestion!

  • Christine Egli Reply

    Great post Francoise. I agree with these areas being handled by a senior/backline team. Any thoughts on what knowledge / content role they should play?

    • ft-admin Reply

      Hi Christine. One of the Backline team’s critical responsibilities is the health of the knowledge base. The Backliners typically own the B-loop of the KCS model for vendors who use KCS and in any case are category owners. And they inspire others to write articles. In particular, whenever someone seeks help from Backline, it’s an opportunity to document the answer if not already documented.

Leave a Reply

three × 4 =

Your email address will not be published.