“Customer service software has evolved so much these past ten years, but they all seem to be solving the same problems!” This was a statement made by a Customer Service leader in a recent brainstorming conversation around decreasing overall Response Times and Resolution Times. 

The role of the modern Customer Service Agent has been growing in complexity. Not only do Customer Service Agents have to manage frontline customer correspondence –  involving a high degree of empathy and communication – but they are also  burdened with navigating through multiple systems, channels, and “sources of truth” to communicate and collaborate with back-office Eng/Dev/IT teams when customer-impacting disruptions occur. The advancement of technology and complexity of internal systems, tooling, and processes have only made matters worse.

To illustrate this point, let’s take the example of a Customer Service Agent who works at ABC, a financial services company, and receives a ticket regarding a failed login. The CS Agent receives the ticket at the top of their queue in their helpdesk system – but in addition to this ticket, they notice they have 50 more tickets waiting in the queue regarding a similar issue. Realizing that there may be performance issues with the Online Portal, the CS Agent escalates the problem to their engineering team for assistance. 

This scenario is where we begin to see the limitations of Customer Service workflows and processes as it relates to traditional Customer Service software. This software has done a fantastic job solving front-office customer communication/ticketing problems, such as organizing and prioritizing the ticket queue in a manner where CS agents can solve and respond to one-off customer requests quickly. But what if the problem requires the assistance of back-office Engineering/Developer/IT resources to resolve a core issue, such as an outage or a bug? 

Customer Service Agents face many challenges around workflows and processes to escalate a technology issue, and then on maintaining visibility on the progress toward resolution. A typical workflow may look something like this:

1. Customer experiences performance issues, submits a helpdesk ticket to Customer Service.
2. Customer Service receives the ticket in their helpdesk system…appears to be a problem with the backend technology.
3. Customer Service Agent switches tabs in their Communication platform. Shouts out in a shared Slack or Teams channel (or sometimes to an individual subject matter expert) to figure out if the back-office is aware of the surfaced technology problem. 
4. In our example, Eng/Dev/IT are unaware. CS Agent consults an internal wiki or a spreadsheet to figure out which team is responsible for the service.
5. Customer Service Agent navigates to another internal helpdesk system (such as Jira) and files an internal ticket. 
6. Once Eng/Dev/IT resolves the Incident, an update is posted into the communication platform.
7. Customer Service Agents must simultaneously switch between their helpdesk ticketing system and their communication platform to gather information and respond to customers. 

Moreover, visibility challenges have the Customer Service Agent asking themselves and others: 

• Is our back-office team aware of the customer-impacting technology issue?
• Is there a fix being worked on?
• What can I tell the customer about the issue?
• What’s the progress on fixing this issue? How long will it take?

Worst of all, once the customer ticket is handed off to technical teams, it is no longer governed by the same business rules and success metrics on which Customer Service is measured.  As a result, First Contact Resolution rates, Response Times, Resolution Times, and CSAT are negatively impacted, because Customer Service lacks the means or visibility necessary for a timely customer response.

Most Customer Service organizations today find themselves siloed off from Technical Teams. This siloing effect is exacerbated by the very tools and systems meant to foster collaboration. For example, Customer Service often duplicates information in various platforms through tedious copy+paste exercises, splitting attention across multiple systems while other teams work through technology issues.

Based on  conversations with both Customer Service and Engineering teams, there is a strong desire to break down the walls of communication and collaboration to enhance the customer experience. Engineering/Dev teams have a focus to reduce downtime by treating customers as another key signal to the health of their digital assets, while Customer Service teams continue to emphasize driving down Response and Resolution Times to meet customer expectations. When a technology issue arises that is surfaced by customers first, Customer Service teams need a streamlined method to escalate customer-impacting disruptions while maintaining full visibility of the customer ticket life-cycle from beginning to end, especially when engaging with Technical Teams to resolve the technology issue. 

This begs the question: How do we empower Customer Service with the visibility and information they need to answer customer inquiries/requests faster and escalate technology issues from the frontlines, when the back-office team isn’t aware of a customer-impacting disruption?

A different approach

When an organization acknowledges that a broken collaboration process between Customer Service and Technical Teams leads to increased downtimes, response, and resolution times, a different perspective is needed. It’s time to recognize customers as another key signal of the health of digital assets.

When “customers are an important signal” is embraced, organizations find ways to break down the walls between Customer Service and Technical Teams. By leveraging PagerDuty as the central nervous system to the rest of the technology stack, as well as the mechanism in which real-time operations are conducted, each team is empowered to “work where they are” without having to leave the system of their choice to engage in the Incident Response process.

By integrating PagerDuty with the rest of the technology stack involved in Incident Response, each team can work out of the system they choose. PagerDuty becomes the “one source of truth,’ distributing Incident information across all the different systems and platforms where each individual team conducts their work.

Unlike the previous scenario of a Customer Service Agent receiving an incident-related ticket at “ABC Company,” the workflow can now be simplified into the following steps:

1. Customer experiences performance issues, submits a helpdesk ticket to Customer Service.
2. Customer Service receives the ticket in their helpdesk system, and notices a problem with the company’s backend technology.
3. Customer Service Agent can check on the health of digital assets via an internal Status Dashboard located directly in the helpdesk ticketing system UI
4. If the technology issue is unknown to the Technical Teams, Customer Service creates and triages an “Incident” to the team responsible for a specific Business Service. alerting only the individuals responsible for the fix.
5. A bi-directional link is automatically created between the Customer Ticket and the PagerDuty Incident. Any progress to resolution flows into the Ticket/Case view in the ticketing platform.
6. The Customer Service Agent receives all information in real-time, reducing the time it takes for them to respond to the customer. 

Best of all, this entire collaboration process occurs directly inside the ticketing system within which the Customer Service Agents conducts their daily work.

By optimizing communication and collaboration processes between Customer Service and Technical teams, you can mitigate the risk of customer-impacting disruptions slipping through the cracks during the escalation process. Customer Service teams can eliminate the need to navigate through multiple systems and duplicating the same information across platforms. As a result, First Contact Resolutions, Response Times and Resolution Times, and ultimately CSAT are improved.