Building a Support Operations Function

Many thanks to Kevin Williams for suggesting this topic.

In small support teams, everyone is focused towards support delivery, with some time carved to address planning, training, tool administration, and other essential functions. As the team grows, multi-tasking becomes more challenging and it makes sense to create a team dedicated to non-delivery functions. This typically occurs as the organization exceeds 20-30 people.

If we define the delivery function to include everyone who is either delivering support directly (customer service reps, support engineers, customer success managers) or managing people who are, non-delivery functions include the following roles:

• Knowledge and self-service management, looking after the website and the knowledge base, knowledge management, metrics, and tools. Self-service management does not usually include the administration of the tool itself, but instead focuses on processes.
• Tools development and administration for the various tools used by the support team. This includes long-term planning for future tool additions and upgrades. For on-premise tools, system administration for the hardware is usually handled by the IT organization rather than support.
• Metrics and data analysis, which includes defining metrics, analyzing trends, and recommending appropriate actions based on metrics.
• Planning for new products and releases, coordinating with the product marketing organization.
• Training, for new hires, ongoing technical training, and process and soft skills training.
• Support marketing, designing, pricing, and selling support offerings
• Process management to define and refine  support processes

Note that these are roles, not positions. For smaller teams, one individual may fulfill multiples roles: training/process management combinations are common, at least when it comes to process and tool training, as are tool administration/metrics. And the roles may be held by support managers (think about process management, for instance) or support engineers (for tool administration), not just when the organization is small but sometimes long after a support ops team is in place.

Can you get these roles staffed from non-support departments? Of course and indeed some roles such as support marketing are often staffed by other departments. Note that, even if you outsource your non-delivery needs, you still need to manage the work. In fact, when I speak with IT teams that administer support tools, their top frustration is that they do not have a single point of contact in the support organization that can organize and funnel requests. Think of it the next time you bemoan the poor service you are getting from IT! Still, some roles cannot be outsourced at all (knowledge management and process management, for instance) and many are likely to receive much more attention and resources if funded within support (such as tool administration and metrics).

It’s usually fairly easy to tell when to create a support operations team: when delivery and non-delivery duties collide. The first roles to be formalized tend to be the first ones on the list,  knowledge/self-service management, tools administration, and metrics, because they require both ongoing attention and specific technical skills, which means they are likely to conflict with delivery duties and cannot easily be handed by the support managers, who tend to have more flexible schedules.

In contrast, managers can often juggle planning and process management along with their other duties, and support engineers, at least some of them, enjoy some job diversity when they can train, so specialization is usually less urgent for those roles. Still, each organization is different and should make its own choices based on the skills of the existing members and the requirements for non-delivery roles.

I am a great fan of the “slightly too small” support operations team. What I have observed is that fully-resourced operations team tend to generate more bureaucracy than results, and also cut themselves off customers’ needs. So by all means hire a knowledge manager, but make her collaborate with the support engineers to create and maintain knowledge. Hire a trainer to create curriculum, but ask support managers to deliver process training. Hire a planner, but assign support engineers to vet the new products. The support operations team members should function as project managers rather than do all the work themselves. With that, the ratio of support operations staff to the overall organization should not exceed 5%, going down to 2-3% as the organization grows.

What are you doing for support ops? Anything you’d like to add? (This will be a hot topic for The Art of Support, Second Edition, so let me know what you think!)