The July 2014 issue of the Harvard Business Review includes an article about coaching that drew my attention. In a laboratory setting (with, I imagine, Psych 101 students doing planks and riding bikes, so not exactly your typical support organization!), silent coaches improved performance by 33% while “vocal” coaches improved it by only 22%.
Why should we care? The study did go a little further and found that good coaches:
- speak directly and personally to the people they coach (duh)
- lead by quiet example
- provides examples of performance that are better than that of the person being coached
- provides opportunities to perform as a team, especially for “weak links” who improve the most in a team format
Maybe team goals deserve another look…
Many thanks for Sam Levy and Neil Lillemark for suggesting this topic.
When talking about case productivity, or resolution time, there’s always a moment when someone will point out that all cases are not created equal. Some cases are easy and will be closed fast and with little effort. Others are complex and will require hours of troubleshooting, and will take weeks to resolve. So it seems that we should try to capture case complexity, right?
I say: not so fast…
- Case complexity is subjective. A case may run long (elapsed time), demand hours of work (effort time), or require many back-and-forth communications with the customer, without being particularly complex. The length and communication intensity could be caused by the inexperience of the support engineer, a lack of technical knowledge, or an elusive customer, rather than the sheer complexity of the case. In some support organizations, some categories of cases will naturally fall into “simple” or “complex” categories, for instance a password-reset request would be simple while a performance-tuning question may be complex. By all means rely on such straightforward distinctions if they apply — but they rarely go very far.
- Case complexity can best be gauged at case closure. It’s often very difficult to tell whether a new case will be complex or not. This means that the level of complexity of open cases, the cases in the backlog, is usually unknown, even though it would be handy to know whether they are lingering for good reason (they are complex) or bad ones (the support engineer is inept). So measuring case complexity is not a big help to manage the support backlog.
- Measuring case complexity does not help customers. The reason to measure complexity is driven by internal concerns to meet productivity or resolution targets, neither of which is important to customers. (Customers do care about resolution time, of course, but they don’t care that a particular case is taking a long time because it is complex.) Expanding effort on activities that do not benefit customers is questionable.
- When it comes to metrics, using average volumes is adequate. The main reason why support managers want to measure complexity is to be able to judge whether Joe’s closing 100 cases of an average complexity level of 2.2 is equivalent to Anna’s closing 50 cases of of an average complexity level of 2.9. But if Anna and Joe are working from the same pool of cases, over time the average complexity of the cases they handle should be equivalent. So yes, today Joe closed 5 easy cases and Anna closed 1 hard case (only), but over a month or a quarter they should be pulling about the same load, complexity and numbers-wise. The reasoning is the same for resolution time: if Anna resolves 80% of her cases in a week and Joe is working from the same pool, then Joe should also be resolving 80% of his cases in a week (again, over time, not necessarily this week).
- Average volumes are fine for staffing models, too. This is the same reasoning as above.
- Short-term audits are helpful. Although the mix of case complexity tends to be quite stable in established support organizations, it’s useful to conduct short-scale audits to check. To do that, take a week’s worth of closed cases (or a day’s worth of cases if your volumes are high) and manually assign complexity ratings to each. You will quickly see whether your mix is changing over time, and whether different categories of cases can be (automatically) classified as complex or simple. This type of audit is a great way to decide whether certain groups of support engineers, because they work on different types of cases, should be given different productivity or resolution targets. (Pair this exercise with a timekeeping audit for better accuracy.)
Do you measure case complexity? If so, please share why, how, and how you use the results.
Working with support engineers, support managers, and customer success managers, I often find that the more kind-hearted ones have a hard time asserting themselves appropriately, for instance when delivering bad news, or setting boundaries. Sadly, customers read less-assertive demeanor and language negatively and are quick to assume that they cannot trust the individual they are working with, or should escalate the issue. I just came across a recent book and a less recent TED talk that address the issue beautifully and practically.
The book, Power Cues: The Subtle Science of Leading Groups, Persuading Others, and Maximizing Your Personal Impact is written for would-be leaders but can be mined to great effect for support situation. Here are some ideas from the author’s experience:
- Open your arms to show openness and to project more. (Open wide, straight out from the shoulders). Note to support practitioners: body language carries over the phone, really! An open posture will translate into a more open tone of voice.
- Focus solely on the person with whom you are working. To practice, recall a strong emotional moment and practice putting yourself into the moment with all five senses. Note to support practitioners: this idea of focus on one person means that you simply cannot multitask. Try it!
- Leverage the “offstage beat”. Actors routinely conjure up an emotional objective before gong on stage. It works just as well for support conversations, as in “I can’t wait to tell the customer about this clever workaround I created for the problem.” Redefine any fear as adrenaline.
- Read openness in others by checking the eyes (wide open, dilated pupils) and the hands (is the hands not shaking yours open or closed?)
- If someone violently disagrees, sit or stand facing in the same direction. We naturally mirror others when listening to them, but in case of an argument you don’t want to mirror. Verbally, I like to use lots of we’s (and very few you’s).
The TED talk, by Amy Cuddy, has the requisite amount of emotional drama, but also stark results from a study on how assertiveness not only shows up through our gestures (no real surprise there) but can be triggered by purposefully adopting powerful gestures. So by lifting our arms up over our heads (out of sight, before that crucial meeting!), holding our arms away from the body, or draping one arm around a nearby chair, we automatically increase confidence — and, per Ms Cuddy’s study, increase our testosterone levels and decrease cortisol, the so-called stress hormone.
My mother used to remind me (over and over) to stand up straight. She was right!
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 November 2014 edition of the FT Word. Topics for this month:
FT Works in the News
Customer Churn Codes
If you are thinking about classifying the reasons why customers leave you, check out this post.
How Companies Succeed in Social Media
An update on the progress of the collective book about using social media for support, edited by Shawn Santos. We have a new title and a publication date of January 2015… I just got my chapter back from the editor so we are getting close!
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