Can shared ownership work for support cases?
Many thanks to Marc Burckin for suggesting this topic.
Most complex-support organizations use an individual ownership model for cases: each case has an owner who is responsible for moving the case forward, including reviewing and responding to updates by the customer (e.g., queries, new information useful for troubleshooting) and internal parties (e.g., Engineering updates). Depending on your case resolution model, the owner can stay the same throughout the life of the case (barring rare exceptions like PTO, or Follow-The-Sun), or the owner can change if the case needs to be moved to a different tier–but at any point in time, there is a single person tending to each case.
In contrast, many low-complexity support organizations use a shared ownership model whereby cases are essentially held in common. If a customer supplies new information on a case, whoever sees it first handles the interaction. There is no individual backlog and no case owners per se, only actors.
Shared ownership can make for faster issue resolution, since, on average, updates are handled faster than if they have to wait until the case owner is available. But it also has drawbacks:
- Customers dislike working with multiple individuals, especially if they are required to explain their story multiple times.
- When troubleshooting requires a lot of context, as is often true for complex support, each new support engineer needs to become familiar with that context. This takes time, and can be frustrating for customers, to boot.
- Managers need to be more hands-on to assign work and manage the backlog.
With that, should you adopt a shared-ownership model?
- You are likely already using it for specific types of cases. Many organizations use a shared-ownership model for highest-severity cases, since multiple individuals are notified of updates on such cases and are expected to act on them as a team.
- You could experiment for low-complexity cases. It can be hard to determine whether a case is simple or complex from the get-go, but you can ask the support engineers (or an AI bot) to tag cases perceived as simple so they can be attended by anyone. Or start with customer service or other categories known to yield simpler cases.
- It is not recommended for complex cases. Customers don’t like the context-learning overhead of shared ownership, and internal efficiency is affected, too. Instead, work on combatting the weakness of single ownership: can you leverage technology and processes to ensure customer responses are handled quickly?
- Expect to revisit how you encourage and reward support engineers who handle shared cases. For instance, if you reward engineers based solely on how many cases they close, they may cherry-pick the ones that they expect to close on the next interaction but leave the gnarly ones untended. Perhaps you can recognize more than one actor per case and implement more group-level metrics in general.
Are you using a shared ownership model? Please share your experience in the comments.
Thanks for posting this FT! Would love to hear from other Support Leaders who have had experience with a shared ownership case model for some of their case volume?
Regards, Marc
I had tried this practice in my team and had framed it under the Agile Manifesto; specifically in the context of Pair Programming. The structure didn’t yield results due to the expectations from upper management in terms of complying with the metrics. The performance review had been tied to the metrics so working on a case with 2 engineers didn’t get attraction. The swarming initiatives have been closer to get results but even with swarming ; the health of the metrics is still a challenge.