Operationalizing Problem Ownership

We often consider ownership an individual responsibility rather than an organizational effort. Here’s why that should change, and how to start the process.

Taking ownership of your customers' problems is one of the first things new customer service and technical support professionals learn. It's a cornerstone of many training programs, including HDI's Support Center Analyst curriculum. When executed correctly, demonstrating ownership behaviors fulfills customers' psychological needs to feel valued, aids in defusing emotional hijacks, and demonstrates a technician's willingness and ability to help them.

Ownership isn't just for IT support! Onboarding is one occasion where I desperately wish more service providers across the enterprise, such as HR and Facilities, would better demonstrate ownership. Starting a new job is stressful for employees, who must learn a new way of getting things done. I recall several occasions when crossing a single item off my onboarding to-do list took weeks of trial and error. I felt frustrated and defeated, which precluded me from feeling content in my new home.

Many service providers struggle to operationalize problem ownership at scale. We often consider ownership an individual responsibility rather than an organizational effort, complicating cases where multiple people or teams are needed to solve a problem. Worse yet, this mindset can disincentivize working as a team.

Truly empowering support teams to own customer requests requires ownership to be baked into our procedures. No matter how much any individual support center analyst or desktop support technician wants to take ownership of customers' problems, they can only go as far as their support organization's process allows. Going rogue would leave them feeling overworked, overwhelmed, and unproductive, ultimately resulting in worse service for the customer.

Ownership Is Good Business

First, taking ownership helps providers manage demand for their services. While it can't prevent printers from malfunctioning or help new employees access the shared drive, taking ownership will reduce the second, third, and fourth calls associated with each of these issues. When we shift responsibility and effort from customers to ourselves, we eliminate reasons to reach out; repeat contacts for the same request drive up service costs without creating value.

Next, taking ownership helps internally-facing support centers create value for their organizations by reducing internal customers’ time to resolve issues. The less time customers spend on hold, explaining problems, checking request statuses, and worrying about issue resolution, the more value our support center creates. After all, support organizations primarily create value by restoring service and getting people back to work.

Finally, employees empowered to take ownership of problems feel a greater sense of purpose, satisfaction, and fulfillment, reducing employee turnover, absenteeism, and other costs. Support center analysts and desktop support technicians didn't enter their fields to pass the buck. Likewise, ownership behaviors will improve customer satisfaction because everyone likes having less work on their plate.

Ownership By Design

When support centers lead with problem ownership as a functional requirement, we can quickly build it into everyday operations. It won't fundamentally change how we work, but it will impact how and when we communicate with our customers. Here are a few ways your support center can pivot towards problem ownership:

Play Offense

If you're unable to complete a request because it's dependent on a prerequisite process or the customer lacks pertinent information, leave a ticket open in an "awaiting information" status and allow the customer to reply to specific questions by email. You also can demonstrate how to use the service catalog or schedule a callback for another time.

Hold On

Unavoidable delays are inherent to issue resolution. Placing tickets in an "on hold" status, rather than directing customers to call back, shifts the burden to us as the service provider, reducing stress on the customer. Most ITSM systems will automatically revert a ticket to "open" when its predefined hold time expires to minimize technician effort, too.

Communicate Proactively

Customers often reach out to check on the status of existing requests, but this isn't the best use of anyone's time. Eliminate anxiety and unnecessary interactions by equipping your team with thoughtful message templates; this establishes a cadence for sending updates, and ensures that ticket notes are publicly viewable in the customer portal.

Trust, but Verify

Difficulty replicating issues, time-dependent processes, and human errors sometimes make it hard to ensure that we completely resolve incidents. Despite this, tickets are usually closed as soon as we believe our work is done. Identifying risky request types and adding an extra step, such as a scheduled follow-up or a quality check by another technician, reduces potential defects, prevents costly rework, and spares everyone frustration.

External Escalation Paths

Complex questions often demand multidisciplinary answers, but few things are worse than being transferred between departments or companies like an unwanted gift. You can reduce customer pain, not to mention the knowledge being lost in transit, by establishing cross-functional escalation paths between your company's service-providing units and close business partners.

SPOC Model

While many IT organizations use a single-point-of-contact (SPOC) model, whereby all incidents and requests flow through a centralized service desk, there are often some exceptions for particular vendor-supported services. Likewise, other units just learning ESM, like facilities or HR, may lack a SPOC altogether. Consolidating contact points improves accessibility, efficiency, and visibility into holistic service performance.

---

Helping everyone on your team take ownership requires a culture shift, and it make take a while, but the benefits make the process worth the effort.