Support is a team sport. I have yet to meet a support manager or executive who does not subscribe to this notion—and at the same time deplores the not-ideal level of collaboration in their team.

What can we do to promote collaboration? The five tips below apply regardless of the support model you are using: tiered, Touch and Hold, or swarming.

Tip #1: define an owner for the customer interface

Collaboration is wonderful, and customers appreciate it when we collaborate on their behalf but they also need order and predictability. Even the most collaborative organizations assign an owner to each issue, whose job it is to bring it to resolution and keep the customer appraised of what’s going on.

For instance, many P1 cases benefit from small-scale swarming, with several team members troubleshooting together. But designate one person to be the interface to the customer. If the case must continue to be worked actively around the clock, designate another contact to drive the customer communication during the next shift (it’s likely the customer will also change contacts during a long case).

Note that the owner is always a support engineer, even if members of the engineering or Ops teams are also working the issue.

Tip #2: make it easy to figure out who can help

Imagine you are a new support engineer. You get a case, and you need help. Who can help? It’s typically very difficult to find the expert(s) for a particular part of the product, or OS, or networking protocol. Even experienced support engineers often default to approaching the folks they know rather than the actual subject-matter experts.

Shorten the time required to find the right person by maintaining a skills matrix, which consists of a list of categories and a rating scheme, typically with 3-5 levels, with everyone’s name on it. Even when they exist, skills matrices are usually very badly maintained. Newer AI tools contain the promise of maintaining skills matrices automatically.

Tip #3: make it easy to help

There are two issues here: how can I find out that someone needs my help (has specifically asked for me, or someone like me) and how can I find cases where I could help (but the owner did not ask for help at all, or did not ask for help from someone like me).

In most support organizations, support engineers are fully utilized so the former issue is more acute, and it’s mostly a tool problem. For instance, the tracking system is Salesforce but requests are made via Slack and the two do not communicate.

Work with the tools team to integrate help requests into the tracking tool. Support engineers should be able to see, at a glance, everything that’s waiting for them: existing cases in their backlog, new cases they could grab, and existing cases where they can provide help.

Tip #4: make it worth it to help

I am convinced that the main reason collaboration is weaker than it should be in support organizations is because we only count case closures, not “assists”. In other words, if I work a case and I close a case, I get one credit. If I work a case and I help on another case, I get… one credit! Support engineers are rational: they will do what they need to hit their number.

It’s hard to measure effective help. (It’s easy to measure formal help, for instance by counting notes in cases other than one’s own, but you can see the potential for gaming that approach.) Here are a few ideas:

• Ask the case owner to rate the help received (It sounds good, but in practice it’s hard to rate a colleague badly. It’s easier to simply collect kudos.)
• Measure outcomes (e.g. the case closed quickly post-help.)
• Use case audits (Helpers are likely to be consistently useful so you don’t need to check every case.)

Whatever you do, celebrate the helpers.

Tip #5: start small

If your organization is entrenched on everyone working their own cases, you want see a spontaneous morph over to collaboration. The obstacles are: making it ok to ask for help (being vulnerable) and making it glorious to help (as opposed to solving one’s own cases)

Start small. Target an area that’s not doing well: it could be system-down situations, or a particular product area, and organize a small team to experiment with it. Once success is achieved there, you can expand to others. Note the opportunity presented by crises. Trying to make a change in something that’s running well is much harder.

Enjoy!

Better collaboration brings:

• Faster resolution times
• Fewer escalations, because issues get resolved faster (and better)
• Hence, better CSAT
• An easier way to build skills, since each member of a collaborative team has the potential to learn something in the process.

If you can convince the team to give it a try, it will be good for customers, for the support engineers, and for you, the leader.

For more information about FT Works  or to read insightful customer support blog posts Françoise has written and posted to her website, check out https://www.ftworks.com/.