Responding to Support Tickets: Internal and Customer-Facing Processes

Bridget Lamb

Hi everyone,

I'm fairly new at a small technology company, serving as the Director of Customer Success. I've discovered a significant gap in our process for handling customer support tickets. I'd appreciate hearing how others manage the process from an internal perspective and from a customer-facing perspective.

Here's the situation:
Support for our legacy products has been managed a certain way that seems adequate for the type of product and the issues reported by customers. We recently launched a new product, and have another product in development, that serve a different customer segment and the impact of a problem, bug, or functionality failure can be more severe. The team that initially triages a support ticket can resolve most legacy product issues directly, but they cannot do so for the new products. Those problems must be handled by the developers (who report to the CTO).

There has been no definition of incident severity and no clear process for handling support tickets for the new products. I drafted a process that identifies 4 levels of severity, with examples for each, and the expected internal response/response time. For example, Severity Level 1, Critical: the ticket must be updated (within Jira) within 30 minutes with a status of In Progress/Requires Development and assigned to someone on the team. Basic stuff.

What's missing are the requirements for the assigned person(s) to provide status updates. Currently it's like a black hole and communication back to me, so I can update the customer, is lacking. Customers don't appreciate "we're working on it" for very long.  Do any of you set parameters for this, by incident severity level? For example, for Sev 1 tickets initial troubleshooting update will be provided back to CS within 4 hours. I understand it takes time to investigate and every scenario can be different, but shouldn't there be some guidelines for accountability?

Surendranath

Hi Bridget,

Let's get to the point straight - handling support tickets for your new (& upcoming) product line.

I appreciate you already have a clear demarcation between the technical support & developers.

In our organization, support triages all tickets and closes whatever they can by answering customers. All of these are functional cases in nature. 
- we use SFDC for communication with customers.

During their triage, if they found that the issue needs a code fix, or any other development is required, they then push it to the development team. However, they will still take the owner for the ticket, which means they own communication with the customer and helps dev engineer in scheduling call with customer, etc.
- Our dev team uses JIRA, and there is a sort of integration between our SFDC & JIRA.

Coming to prioritization & responses part.

All our tickets are prioritized like this - P0 (outages), P1, P2 & P3.

We have different response timelines for each priority, and as each day pass, the scores for the ticket get added accordingly. The scores help in getting the manager's attention (both support mgmt or dev mgmt).

Usually speaking, we need to update every day to customers on P1 tickets.

In addition, there are some daily calls between support & dev teams (managers or directors), where they discuss the priority tickets and status. This helps in prioritizing any escalated issues/customers.

Even with all these in place, we still do face a lot of difficulties in giving meaningful responses to customers every time.

Let me know if you are looking for any specific answers.

Thanks,

Bridget Lamb

Thanks Surendranath. I appreciate hearing how another organization is operating. I think I'm on the right path here.

Ido Barnoam

Hi @Bridget Lamb

If I understand the scenario you describe correctly there is currently a gap between what the support engineers can handle directly and what needs to be escalated to dev.

In my previous company I had a very similar situation where I was establishing a new support team to support our new product. Since the product was new most of the knowledge was in the dev team, so the support people I recruited had very little to work with. Most things needed to be escalated to dev. This caused a lot of cases like you to describe where customers didn't appreciate the same answer over and over while the issue was being looked at.

The way we handled this eventually was to have a dedicated dev on call. This would be a dev team member which was on call (day and night) in case something was needed to be escalated. The team member would change on a weekly basis. In case a support engineer needed to escalate a case, it would do so to that person and would communicate the priority accordingly.

We established internal priorities for tickets  (p1,p2 p3, etc.) each with its own definitions. These would be conveyed internally when the ticket was escalated, so the timeframe and criticality were clear to the dev team as well. The priorities were communicated externally to the customer if the support engineer decided to do that (in most cases it was shared with the customer).

This process meant that while the support person still owns the ticket and the external communication, the actual resolution is owned by dev. What we saw is that gave a lot of clarity both to the dev team and support engineer on where things stand. if there was a delay in predefined times for the priority assigned to tickets, this would be conveyed to the support engineer, which almost always shared this with the customer as well. so the customer had visibility to where things stand with each update.

In my current company, we have a very similar process where we have a team which is on call. Our support engineers escalate cases with a priority, and priorities have an established response and resolution times. These priorities are derived from our general support SLA's which is communicated to our premium customers. The support engineer decides what is the internal priority based on his discretion according to the ticket, customer size, bug severity, etc. 

I hope this helps.
If you want any more clarifications, feel free to DM me.

James Conant

Hi Bridget - 

I've experienced the same issues, except mine were the result of scale and platform stability. The business grew so fast they outran their capability. There were many problems that arose as we transitioned to a new stack and as a result, my team was faced with the daily challenge of "we are working on it" responses from overworked internal teams and stressed from providing such responses to our customers. Obviously, this situation can harm customer relationships as well as create a very intense and stressful work environment for your team.  Even worse, it can lead to finger-pointing between teams which results in walls. Very bad when you have to be able to influence others when answers to your customers' challenges are found inside your company.

I can offer a few tips:

• Define and categorize the type of issues your team faces. Measure their frequency. Measure the time between open and closed. Determine their severity
• Use that information to Co-Develop SLA's between internal teams. Gaining public consensus (acceptance/agreement within meetings etc)  is necessary. 
• Armed with that information, adjust and align your customer SLA's if necessary. 
• Establish a cadence between your teams to discuss dev roadmaps and status. Assigning a member of your team is good. Advocate for your customers. Dev priorities can compete with yours. Education is key and some arm twisting when needed.
• Be TRANSPARENT with your customers for those issues that have unknown diagnosis and timeframes. Sometimes " we are working on it" is an honest answer. In these situations keeping customers advised of status is necessary although uncomfortable. There is always a fear of customer churn as a result (it will happen). 

I hope I am on point and you find this helpful. Feel free to reach out if you need help.

Jim


 


------------------------------
James Conant
------------------------------
-------------------------------------------
Original Message:
Sent: 10-08-2020 13:51
From: Bridget Lamb
Subject: Responding to Support Tickets: Internal and Customer-Facing Processes

Hi everyone,

I'm fairly new at a small technology company, serving as the Director of Customer Success. I've discovered a significant gap in our process for handling customer support tickets. I'd appreciate hearing how others manage the process from an internal perspective and from a customer-facing perspective.

Here's the situation:
Support for our legacy products has been managed a certain way that seems adequate for the type of product and the issues reported by customers. We recently launched a new product, and have another product in development, that serve a different customer segment and the impact of a problem, bug, or functionality failure can be more severe. The team that initially triages a support ticket can resolve most legacy product issues directly, but they cannot do so for the new products. Those problems must be handled by the developers (who report to the CTO).

There has been no definition of incident severity and no clear process for handling support tickets for the new products. I drafted a process that identifies 4 levels of severity, with examples for each, and the expected internal response/response time. For example, Severity Level 1, Critical: the ticket must be updated (within Jira) within 30 minutes with a status of In Progress/Requires Development and assigned to someone on the team. Basic stuff.

What's missing are the requirements for the assigned person(s) to provide status updates. Currently it's like a black hole and communication back to me, so I can update the customer, is lacking. Customers don't appreciate "we're working on it" for very long.  Do any of you set parameters for this, by incident severity level? For example, for Sev 1 tickets initial troubleshooting update will be provided back to CS within 4 hours. I understand it takes time to investigate and every scenario can be different, but shouldn't there be some guidelines for accountability?






------------------------------
Bridget Lamb
Director of Customer Success
------------------------------

Bridget Lamb

Ido, thank you for responding. I love the idea of an on call dev person.

Since my original post, I drafted a support process document, with the goal of making it a customer-facing document. I included a section on issue/ticket severity, definitions, customer response/update timeframes, and target resolution timeframes. I met with the relevant internal leaders and I've gotten push back on the target resolution times, even with caveats to address delays caused by the customer, situations requiring outside parties, etc. Others seem unwilling to put any parameters down on paper and sharing it with customers. I believe in transparency and telling customers what they can expect, doing our best to meet or exceed expectations, and communicating the status honestly even if unexpected things occur. I have more work to do to get buy in here.

Bridget Lamb

Thank you Jim, you are exactly on point. I've started one step in the process by drafting a document about our support process, issue severity levels, and target response and resolution times (see my reply to Ido in this thread). I've asked leaders of the other teams for input on realistic resolution times. Unfortunately they object to putting any timeframes down on paper, even with stated caveats and exceptions that could impact resolution. I agree with being transparent and regular, honest communication with customers, even if it's uncomfortable. I have to work on buy in and shifting the mindset here.

Matt Vadala

Thanks for bringing up that valuable point @James Conant. Support should have some relationship with dev. However, I completely hear your struggle @Bridget Lamb. Have you thought of trying to bring your proposal to the CTO to get executive buy-in? Hopefully the organization can come together as one cohesive unit serving customers rather than siloed departments doing all their own thing.

I project that once being held to some severity based SLA, the dev teams will alter the construction of the new products in such a way that issues won't lead to such widespread outages, ultimately benefitting your customers in the end

James Conant

Thanks Matt. Gaining exec buy-in for the development of SLA's is always needed and most would surely give it. Before going that route I'd make sure you truly understand why they are reluctant to commit to SLA's. They may be resource-constrained and unable to make a commitment. Or, they may be lacking an operational framework (e.g., mapping business functions to IT and then to operations etc.) and are unable to deliver due to dependencies outside their control, etc.  Maybe there is a perception gap between the team and their leader, for good reason or not (very common as the flow of info is passed up the chain). Going over their heads before knowing their concern(s) could damage the relationship between CS and Dev. I am a firm believer in the adage "seek first to understand, and then to be understood". Take someone to lunch, or go for a walk, or etc. Build that bridge to them and go from there.