Why QBRs don’t work — and how to fix them

Most enterprise Customer Success organizations hold formal quarterly business reviews (QBRs) with customers. QBRs should afford wonderful opportunities to share knowledge and improve the connection with the customer — but often customers balk at scheduling them. Why?

  1. They last too long. Customers have lots on their plate and they, especially executives, don’t want to spend time on things that they see as irrelevant.
  2. They are not relevant to the customer’s concerns. You want them to hear about your wonderful new features, but they are concerned about their bottom line.
  3. They take too long to prepare. Gathering data, creating a custom message, and wrangling everyone’s schedule takes hours you could be investing in other pursuits.

The cure? Focus the QBR on the customer, not you, the vendor. Specifically:

  • Know and talk to the customer’s goals. What is your product/service doing to foster the customer’s strategic goals? (If you do not know what the customer’s goals are at all, you are in no position to hold a QBR!)
  • Talk about product fit. Discuss how your product meets customer goals now (this includes features, performance, and service) and how future enhancements may enhance the experience.
  • Bring relevant guests. Customers love it when they can have time with a product manager, for instance — even if the interaction is very short. Bringing guests enhances your status as a CSM, by the way, rather than diminish it.
  • Go short. If you cannot make your point in 30 minutes, you do not have a point. Better have a strong short meeting than a long, meandering one!

And on the logistical side:

  • Use templates. Think of templates as shortcuts to having to invent a new structure every time. You will customize, but faster. Templates also allow you to generate data easily because standard reports can be run for all customers, even if you only use a subset for each QBR.
  • Rehearse, including any guests you are bringing to the meeting. A short rehearsal vastly improves the end product, and in particular allows you to identify the critical points you need to make. If stakes are high, rehearse with your customer contact.
  • Delegate scheduling.  Scheduling is hard because (1) your current QBRs are not great so no one wants to attend and (2) you are trying to coordinate people whose schedule you cannot see. Prepare a great session, and let your contact schedule on his or her side.

What is your experience with QBRs? Share in the comments.

Shift Handoffs

Many thanks to Antonio Orozco for suggesting this topic.

Cases handed over from one shift to another are trouble magnets: information is not passed on properly, customers don’t like working with multiple support engineers, and sometimes the cases just fall into a black hole. Here are 6 steps to make peace with handoffs.

Step 1: Schedule to avoid handoffs

If support engineers routinely grab new cases at the end of their shifts, cases will spill over to the next shift. And if you have customers whose work hours don’t match those of the support engineer who picks up their cases, you will get pressure from these customers to keep working cases past shift-changing times.

For both situations, stagger the shifts to avoid mass departures at a set time. Even small staggers help if that’s all you can achieve. (And of course you can always ask support engineers to stay late to complete case work, but that won’t always work, or work for extremely complex cases.)

Step 2: Qualify handoffs

Much can go wrong during a handoff so the first idea is to reserve them for situations that truly need them. For instance, a system-down situation impacting a customer’s business is an obvious candidate for a shift handoff, whereas an issue that might reoccur can safely wait in the owner’s queue. Establish your own criteria. For instance:

  • If the customer is down and is available for collaborative troubleshooting, we will work continuously and do a warm handoff. Most teams find that only a couple of cases require warm handoffs each day, especially if step 1 was followed assiduously.
  • If the case may require attention off-hours but is not a candidate for a warm hand-off, specific instructions are left in the last case note and, depending on criticality, a heads-up can be given to the next manager on duty.
  • If the case lends itself to offline troubleshooting, it is placed on a task delegation or automated handoff list with no warm hand-off and no special designation. (This is a common way that support teams take advantage of offshore teams.)

Step 3: Structure the handoff process

For automated handoffs all you need is a queue to place the cases being handed off. It’s usually best to maintain a single incoming queue per shift to avoid confusion: all new cases and all handoff cases go on the queue and are worked in order of SLA urgency.

For monitoring-only cases, a heads-up to the next manager on duty may be appropriate — or nothing at all. If a problem occurs, the case will be retrieved and worked.

Warm handoffs may occur between support engineers, between support managers, or from the sending support engineer to the queue manager. Each method has pros and cons and the choice will depend, in part, on how cases are assigned. I recommend the support engineer to support engineer method since it is the most direct, and the most comforting to the customer. Start an internal chat to identify the next owner a few minutes prior to the end of the shift. You can choose to mandate a heads-up to the manager-on-duty, but deliver the briefing directly to the person who will actually work the case.

Step 4: Return to sender

Multiple handoffs increase the likelihood of “spaghetti cases”, cases that are touched by many hands but never moved to any kind of stable troubleshooting progress. A good practice is to assign a permanent owner for all cases, usually a support engineer in the same time zone as the customer. If a case occurs off-hours and is not resolved by the end of the shift, it goes to an owner in the customer’s home base. If a case is handed off by the daytime owner, it eventually returns to him or her if not resolved off hours.

Even with multiple handoffs, limiting the number of owners is a big help.

Step 5: Match bodies and cases

Often, handoffs are painful because the receiving team is overwhelmed or resentful of the extra work. Make sure that headcount and incentives align with receiving handoffs. If receivers get no credit for their work, surely they won’t work quite as hard on transferred cases.

Step 6: Use metrics to ensure quality

Do you know how many handoffs occurred last night? Last week? How many cases were handed off more than 3 times? If not, you need better metrics. It’s also useful to appoint a Follow-the-Sun manager to monitor handoff metrics and oversee (and improve) handoff processes.

Last idea: when a handoff goes wrong, it is useful to hold a post-mortem to identify what went wrong, and improve the process (or adherence to the process) for the future.

Do you have more ideas to improve end-of-shift handoffs? Add a comment!

 

Incentives for Support

Many thanks to Ben Williams for suggesting this topic.

Ben asked how best to motivate and incent support engineers. Let’s start with basics:

  • Motivation is an internal, downstream phenomenon. We can’t really motivate other people to do anything, but we can built an environment that brings out the best in the team.
  • On the other hand, it’s quite easy to kill motivation and discourage team members. (Yell at people, set unattainable targets, play favorites and see what happens.)

Before thinking about incentives, create a rational performance management system:

  • Define work processes that make sense. My pet peeve is having to ask permission for every little thing. Trust your team members (once trained) to log bugs, close cases, or post knowledge base documents. You can verify, of course, but after the fact.
  • Define outcome-based metrics that cannot easily be gamed. For instance, the number of cases closed (resolved) per week is an outcome, whereas the number of cases worked in a  week is an activity. If you place targets (quotas) on activities, you will get activities, but not necessarily results (e.g. someone will write a bot to update all cases every day to meet your activity goal of touching cases every day). So think long and hard about metrics that will be the subject of quotas and targets.
  • Provide frequent feedback, both positive and constructive.
  • Take action with team members that are not pulling their weight. It’s demoralizing to be working hard while others lounge, apparently with impunity.
  • Provide opportunities for personal development and growth.

With a performance-management system in place, you can think about incentives. Here are 7 ideas to ponder:

  • Base recurring awards on standard metrics. For instance, recognize the team member with the highest customer satisfaction ratings, or the individual who collected the most links on their knowledge article (think about that one: it’s powerful!)
  • Balance goals: for instance, the award goes to the individual with the highest customer sat but only if s/he closed at least X cases.
  • Reward great performance, not just the greatest. Support teams tends to be group oriented so think about giving recognition to everyone who exceeds a certain (high) target rather than the one individual with the highest score. Along the same lines, reward entire teams for extraordinary performance across the team.
  • Add random awards: Alongside regular, predictable awards (e.g., highest customer sat, most-used knowledge base articles), create awards for non-recurring great behaviors. For instance, best knowledge base cleanup (just this quarter, if it was a priority).
  • Think about slow-and-steady awards. It’s so easy to recognize the hero who saved the day, but harder to recognize the individual who consistently prevents escalations. How about a perfect-year award (for hitting high customer satisfaction ratings not just this month or this quarter, but the entire year)?
  • Use people-choice awards. Ask for nominations and select from them so it’s not just a popularity contest and you can ensure that the awards are rooted in behaviors that benefit the team.
  • Award money, or not. Money is great but not required. Make sure the amount is not too small, so it does not backfire as an insulting pittance. And don’t roll the money into the regular paycheck, where it will get lost. Public recognition works, although some recipients will be shy about it. Intangibles (e.g., juicy projects, special schedules) are great, especially if tailored to the recipients.
  • Step back and assess. If you have been running an award program for a while, review the recipients. Are they the ones who regularly, cheerfully, amazingly get the work done? If not, tweak the program.
What have you done to establish incentives for your team?

Metrics for Customer Success

In the last installment in our series about Customer Success ROI, we talk about metrics for Customer Success. Metrics are of course used for many other purposes beside ROI calculations so we will start with the trusty balanced scorecard (discussed here in the context of support):

If you are thinking about ROI, the Financial Performance quadrant is most important and one of the critical task is to clearly define how you measure renewals. You can measure them in a number of ways:

  • Raw renewals bookings, i.e., $ renewed / $ for renewal. In this case, renewals will always be less than 100%.
  • Net renewals booked, i.e. $ booked/$ for renewal. In this case, renewals can be higher than 100% since upgrades are included in the numerator.
  • ARR growth, i.e new ARR/old ARR (or sometimes MRR). This is different from the above in that it reflects ongoing recognized revenue rather than bookings.

Whichever you choose, carefully analyze lost business. In particular, healthy net renewals could hide painful losses for certain products, customers, or customer segments.

On the cost side, the example above shows the customers/CSM ratio but if you have onboarding specialists you will also want to add the customers/onboarding rep ratio — and both are used in creating the staffing model.

Have you implemented a balanced scorecard for customer success? How did that work for you?

(If you’d like to read more about ROI for Customer Success, the first installment discussed the wisdom of not doing ROI analyses. The second showed how to calculate benefits. The third discussed how to create a staffing model. The fourth described how to create and deliver a persuasive ROI presentation.)