Embrace the SPOC

“How can we get other departments to stop treating us like a SPOC and own their communications?”

This question came up during an audience Q&A portion of SupportWorld Virtual, and we ran out of time during the webinar to answer it. The question is a good one to help us better understand shift left and service management’s value to our organizations. I shared some thoughts about it on Twitter, but would like to expand the discussion here.

What Is a SPOC?

The idea of a SPOC (a single point of contact) is to route all communications through a single entity like a service desk. The SPOC model can be single, multi- or omni-channel where users use all sorts of strategies like email, phones, walk-up support, or others to communicate and request services or log incidents. That SPOC usually acts as a frontline or tier-1 group that is both triage nurse and nightclub bouncer in order to orchestrate the flow of tickets to other teams.

Join Chris for his session at SupportWorld Live, Innovating in ITSM: A Mad Scientist's Perspective on Continual Process Improvement!
Join us!

Bottleneck or Funnel?

The primary critique with the SPOC model is that it creates a bottleneck at the service desk level where all communications in and out of your ITSM systems now flow through one point that is susceptible to shifts in volume. In order to overcome this, it is important to shift your mindset from bottleneck to funnel. The SPOC is not meant to slow things down, but to enable your organization to shift left by empowering your tier-1 workers with the access, training, and knowledge to resolve tickets without escalating.

A common problem that exists in organizations that do not embrace and enforce the SPOC is that the work starts to shift right. Users learn which team(s) work on which tickets and start sending emails directly to tier-2 or tier-3 workers even if they are things that the service desk can easily handle. Many times, those higher tier workers do not push back on the users on the auspices of being helpful. This can waste their time, and (usually) means tickets are not being entered or logged for these requests. This can have downstream impact on reporting, KPIs, and of course productivity and total cost of ownership. Without using the SPOC model those higher-tier workers are spending a lot of time doing their own duties in addition to now acting as a tier-1 support.

When these tickets or emails go right to higher tier teams, we can also lose consistency in handling. A person on the accounts team may have a guess at how the network onboarding works but may not provide the correct policy or procedure for it. Wrong answers can lead to confusion or shadow IT support or could come back to bite us down the line when a user references an inconsistent answer in a disagreement. Beyond this, if they do not know the answer and do not want to guess, we now have to start creating a policy for re-routing tickets or how to send issues between teams.

Orchestration. With the SPOC model, you can have one team that can manage the flow of tickets and act as the conductor orchestrating each ticket appropriately. A huge benefit of this is when a ticket may need to be split or go to multiple teams. A service desk can be trained to handle this and know which teams fulfill which components of a request, whereas a higher tier team may end up playing ping-pong with the ticket, leading to an overall poorer experience for the user.

Communication. Another consideration for embracing the SPOC is that having a SPOC allows you to monitor and control communications. Training one team to have consistent and effective communication style and tone is a lot easier than training an entire division. By using the SPOC model, you can closely monitor how things are responded to, documented, and resolved with higher tier teams. Your service desk can receive training on delivering excellent customer service, but your higher tier teams may not have interfaced with users in a while. This can lead to the notorious ticket resolution of “DONE” being sent to the user, or the other end of the spectrum, where an engineer may send too much information, including technical jargon that confuses the user.

Monitoring. Centrally monitoring incoming tickets and emails can be essential to spotting outages, problems, and major incidents before they get too big. If items are all routed through a SPOC to one queue first, we can better understand what trends are occurring in real time. If those tickets are distributed round-robin to several teams, it can take us much longer to realize that something bigger is happening.

Centrally monitoring incoming tickets and emails can be essential to spotting outages, problems, and major incidents before they get too big.

Better Service Delivery

Being the SPOC is a powerful position that helps enable a stronger shift-left strategy and the delivery of consistent and high-quality customer service. While it may feel like taking on extra work, the benefits can outweigh the increased workload and help cut down on rework. Embracing the role of the SPOC enables you to add value to your organization and provides you with insight that could otherwise be lost. Being a single point of contact might not be so bad after all.

Chris Chagnon is an ITSM application and web developer who designs, develops, and maintains award-winning experiences for managing and carrying out the ITSM process. Chris has a Master of Science in Information Technology, and a bachelor’s degree in Visual Communications. In addition, Chris is a PhD Candidate studying Information Systems with a focus on user and service experience. As one of HDI’s Top 25 Thought Leaders, Chris speaks nationally about the future of ITSM, practical applications of artificial intelligence and machine learning, gamification, continual service improvement, and customer service/experience. Follow Chris on Twitter @Chagn0n .