Create and Swarm on an Incident

Learning Objectives

After completing this unit, you’ll be able to:

Describe when and how to swarm on an incident.
Explain when and how to create incidents, problems, and change requests.
Step through determining the root cause of a problem.

An Incident Happens

Ada gets the chance to test Customer Service Incident Management when cases start coming in where cables going into solar panels are starting to smoke before shutting down. She sees five cases and worries that more will arrive.

In her entire career, she’s only seen one solar panel start smoking. She rereads the knowledge article she created about that closed case, but it doesn’t seem to be relevant here. In that case, someone had slammed into a panel and broken some components. It seems unlikely that a random breakage would happen at five different customer sites at the same time, so this issue looks like something new.

Either way, smoking solar panel components is always serious and the fact that it’s affecting five customers raises it to the level of an incident.

Create an Incident

Ada wants to track these cases as a widespread customer incident. She uses Service Console | Incidents to create an incident and add the related cases. Because the S-1000 Solar Panel is the asset having problems, she adds the asset to the incident record too.

Finally, she sends a Slack message to her customer support team channel telling her agents to send any cases about smoking solar panels to her. In that message, she links in the knowledge article for shutting off solar panel installations so her agents can find it quickly.

Swarm to Identify the Root Cause

Ada looked for knowledge articles about this problem, but she didn’t find anything relevant. She doesn’t know the root cause of the problem, but she knows that there’s no workaround, so she starts a swarm in Slack on the incident to get company experts’ help in solving this problem.

She uses Expert Finder when creating the swarm to locate team members with the right expertise and availability. She makes sure that the senior service level agreement manager for Ursa Major is in the swarm to make sure they’re meeting all customer Service Level Agreements as they go through this incident.

In the swarm channel on Slack, Ada talks to solar panel expert James C. about the problem. She suggests that they add in the top expert for this kind of solar panel, Gertrude Stone.

Slack channel showing the incident number and Ada and James discussing adding Gertrude

Gertrude joins the channel and quickly reads through the messages and incident information. She posts that it’s a rare problem, but she has a theory about the root cause: Record high temperatures are making the panels overheat. When they get too overheated, they’re shutting down.

Ada creates a Problem record to track their findings. First, she contacts customers to get temperature readings for their panels to see if Gertrude’s theory is right. Then she reports back to the swarm that the temperatures on the customers’ roofs are around 130 degrees Fahrenheit (54 Celsius). The solar panels themselves are about 180 degrees Fahrenheit (82 Celsius). She updates the Problem record with this information.

In the Slack channel, Gertrude mentions that this is outside the approved operating temperature for those panels. The panels are older and she worries that one of the components might have overheated. So she’s dispatched to the nearest customer site to inspect a panel for damage to confirm her theory. When she dismantles it, she identifies the overheated component.

Before she leaves, she makes sure that all other S-1000 solar panels on the roof are disconnected from their power grid because they’re also way too hot. She sends a message back to the Slack channel and Ada updates the Root Cause Summary field in the Problem record with her findings.

Now that they know what’s wrong, the team is ready to fix the problem.

Start Fixing the Problem

Gertrude creates a Change Request to capture the steps required to fix the problem. Then she creates a remediation plan with high-level requirements necessary to fix the problem.

Identify related assets and contact customers.
Replace defective thermoregulators.
Contact the manufacturer for a warranty refund.
Develop a plan to remove these panels from service.

On the new Change Request record, Gertrude chooses existing work plans that detail specific steps needed to address each of her high-level requirements. If these work plans didn’t exist, she’d have to create them.

Finally, Gertrude links the Change Request record to the incident. Now the Incident record contains all the information about the problem and everyone can see what they need to do.

Finish and Close the Cases

Ada steps through the work plans in the Incident record. First, she identifies customers who are still using the S-1000 panels. She creates work orders for each panel. Field service technicians are pulled off their regular jobs and dispatched to the customer sites immediately with new thermoregulators. In just a few hours, all the solar panels are fixed and back online.

Ada sends an email to all related cases to recommend that the affected customers upgrade to newer solar panels or remove them from their power grid during very hot days. Then she closes the cases.

Finally, she adds a member of the warranty team to the swarm’s Slack channel. She suggests that they pursue getting refunds from the solar power manufacturer who created the S-1000s for the replacement parts and refers them to the Incident record.

Ada had a busy day. She identified an incident and got it fixed for her customers, creating an incident record and working with her team to figure out and solve the problem. Customer Service Incident Management made working through this incident much easier for agents and customers alike.