The need to scale came up on two recent TheCR Network roundtable calls. On one Jeremiah Owyang of The Altimeter Group addressed potential causes of burnout as well as suggested the development of an escalation path as a way to scale thus avoiding burnout. Knowing the breadth and depth of experience the members of TheCR Network have we went one step further and threw it out to them. Christian Rubio shared his prior experience in that discussion thread and it was so great we wanted to share it with you all:
- Segment your customer requests by monetization tier/LTV of the member and by the criticality of the type of issue. Knowing your engagement KPIs at all times is critically important, so you know where and when to escalate certain issues. Once you have prioritized for key types of issues and by LTV tier, you will probably be surprised by how much Time to Resolution is reduced and how quickly your Customer Satisfaction scores jump. This approach protects your revenue streams and demonstrates respect for the non-premium masses who’ve likely done the heavy lifting in building your brand.
- Track device characteristics of user reports to identify patterns. Quite often an app or feature works great on one device or browser, but it suffers performance issues on another. When it comes to identifying issues, you can reduce Time to Identification by a Support rep or CM and even further reduce Reproduction Time in QA by tracking and reporting relevant browser/ device info precisely. We actually found most third-party case management software to be deficient compared to a combination of Gmail with home-grown logs and dashboards to efficiently collect key user data. In CM, we segmented and studied monthly usage logs to identify patterns of deficient performance or over-indexation of reports by device model, browser and many other characteristics, and we would reach out to members and engage them directly for user experience feedback. We’d then compile the information and report it internally. CMs and Support (I oversaw both, and they worked closely together and knew each others’ tools) also had access to real-time dashboards to identify sudden onset of potentially critical issues.
- Server alerts. If you suddenly get a spike in reports during off-hours, server alerts to your email or phone number will save you digging out of some serious Support or CM queue muck in the morning or, worse, on Monday after a long weekend of no coverage. The alerts should give you or lead you to an instant first glimpse of the severity and reach of an issue, which, if you put some smart rules in place, can get you in front of an experienced, trusted member who can give the kinds of details your bleary-eyed Chief Engineer wants when you get her on the phone at 3 AM.
- Make sure your FAQs are up to date. We worked in tandem with Product consistently to anticipate likely FAQs for new features at release (particularly when we gave alpha and beta-stage feedback to them). Investing in a service or feature that allows people to provide instant feedback on your Help section proved valuable in reducing the number of emails we received, as we regularly checked user ratings of our FAQs and set thresholds for when it was time to revisit our copy for clarity and conciseness. Clear, concise answers reduced customer touches and made for easier translation and mobile optimization.
- Culturally, everyone in the company was expected to do some CM work. I was lucky to work at a company so focused on the user experience and CM. The founders enforced the policy that all new hires were to spend their first week in CM and Support – before they did their own jobs or met their team. The results were fantastic: CM was constantly infused with fresh perspectives and ideas on improving our work flow for scale, and new hires felt fully up to speed on why they were there before ever touching a line of code or product spec. This policy had an extra, important effect for me as a manager competing for resources: everyone from engineering to marketing to HR and finance knew the community well and were deeply empathetic to CM resource needs. I rarely had to fight for additional headcount or development resources. From a cultural perspective, members of other units who were looking for insights on the community learned HOW to ask CMs the kinds of questions that would get them to their “a-ha” moments…usually something like, “Hey, Christian, why do members do X? What does it mean? Is it something we could leverage?” You can imagine how much pressure that took off of the CM team as the eyes and ears of the company, and how much more fun it was to write user stories that you knew had an interested audience.
Managerially, I could (and now realize I should) write a chapter on managing against CM burnout, but here are three things I worked on constantly:
- Resources vs. time. Whenever asking for additional resources, I would remind my executive team that great CMs love what they do and, given the choice between more money, more time off or getting the tools that would improve work conditions, they’d often take the latter. More often than not, neither carrot nor stick were necessary – just better horse shoes.
- Learn your community’s activity patterns, and schedule coverage for it. Just-in-time coverage helped us combat bloat in the CM team, along with properly prioritized queues. Traffic congestion follows logarithmic patterns, as do backed-up queues. Automate every step you can in issue investigation work flows, and focus more energy on monitoring information flows. We knew which hours of the day were most likely to see spikes in attempts to upload illicit content, when spammers were likely to run scripts, and we staffed accordingly. Consider shorter work weeks with longer hours in a day per CM to give them plenty of recovery time, and institute mandatory breaks. You don’t have to run an environment like a call center; as a matter of fact, when things were running as designed, our CM team had time to play foosball or video games, or they would be farmed out to work on product, marketing projects or performing competitive analyses for the founders. We also made it crystal-clear to our members when the light was on and off as far as Support and CM were concerned, with instructions on how to reach an admin in a bonafide emergency. And yes, those calls were taken 24-7, no answering service allowed.
- Prioritize. Convey to your CM team what exactly you view as the most important and least important aspects of their job, and back it up with monthly and/or quarterly reviews that score them based on those priorities. That really brings home to them their priorities, and that clarity helps keep unnecessary work (and stress) down. If you have the data and the resources (ie – time, technology and budget), visualize their performance and benchmark them against their team and themselves. Don’t breathe down their necks: they make more judgment calls on an hourly basis than anyone in the company. The last thing they need is a manager who shakes their confidence. Short of a serious exposure to liability, unethical or illegal act, use a problematic incident as a case study. Look inward at why they didn’t know what to do, and take the opportunity to deepen everyone’s understanding. Every incident is a learning opportunity.
We couldn’t agree with Christian more and hope this glimpse inside TheCR Network is useful and helps you address burnout on your team.
———————————————————————————————————————–
TheCR Network is a membership network that provides strategic, tactical and professional development programming for community and social business leaders. The network enables members to connect and form lasting relationships with experts and peers as well as get access to vetted content.
TheCR Network is the place to learn from social business practitioners. Join today
