Search
  • Better Process Company

Case Study: Merging Incident Management Systems.



The Background

An African focused sports betting company had recently merged with its platform supplier and needed a single system for managing incidents. They were planning to expand their offerings to include online games and virtual sports betting and have significant growth planned by expanding into other countries.


The Situation

The current process for incident management contained numerous manual notification and communication steps. Information was being lost and there was little feedback, and zero progress visibility for customer support teams. Any incident went through at least three tools and potentially as many as five. Mainly they were logged in SalesForce, then in JIRA Service Desk, and the ticket number communicated with IT and support teams via Skype.


SolarWinds Service Desk was also being used by part of the organisation for managing service requests, but not customer incidents, and for asset management.


The Goals

  • A single view of incidents, with a path to link them to problems.

  • Integration with the customer support platform (Salesforce).

  • Feedback and updates provided to the team.

  • Clear escalation paths and notifications of serious incidents.

  • A single source of truth for all incidents.


The Process & Problems

After an introduction meeting, a series of one-to-one meetings were held with all stakeholders. This gave them an opportunity to discuss their needs in detail and highlight any areas of concern they had. This was an important first step in gaining buy-in to the changes.


Everything was collated into a report, with recommendations and an improvement plan that was sent to the senior management team. This was then distilled into a presentation which was delivered to all stakeholders.


The decision was made to make SolarWinds Service Desk (SWSD) the incident management hub, integrate that with SalesForce and provide an escalation path into JIRA for incidents that needed it. This presented several challenges.

  • The whole SolarWinds set was configured to support service requests.

  • The defined categories in the tool were confusing.

  • There was a lack of internal knowledge on how to customize SolarWinds.

  • Tool knowledge was siloed.


In addition, there were issues and challenges not related to the tools.

  • Lack of clear definition for escalation path.

  • No agreed incident severity levels.

  • Uncertainty over who needed to be notified and when.


None of these are unusual problems. Whenever two teams or companies merge definitions and work-flows are going to become unclear. This presents an opportunity to make the new systems better than either of those being replaced.


The Solution

With SWSD to be the hub for incident management and therefore the source of truth the set-up of the tool needed to be reconfigured. New categories were added and existing categories were consolidated. Reporting forms were redesigned to cater for incidents and provide a logical division between service requests and incidents. With that division established it was possible to create assignment rules to route specific incident types to the appropriate teams.


An agreement was reached on the classification of the severity of events. The allowed notification system to be created that alerts the relevant people at different levels of the organisation to critical incidents. It also provides customer-facing leadership visibility of incidents raised by their teams and any updates.


The integration between SWSD and Atlassian’s JIRA involved a number of people but was straightforward. The integration with Salesforce was more problematic. There is no direct integration between the tools, but a couple of third parties provide mechanisms to pass between them. There was a show-stopping feature of all the integrations tested. None of them could provide the desired behaviour between the tools. The desired behaviour was that when there was an update to an incident in SafesForce that had already been added to SWSD, the SWSD ticket would update. This didn’t happen. Instead, whenever a comment was added to a SalesForce incident a ticket would be created. In light of this, and plans to replace SalesForce, it was decided to remove the integration requirement.


The Results

At the end of the time allotted for the business goals had been achieved.

The customer support team reported a better understanding of what incidents had occurred, who was responsible for fixing them, and more up to date information about progress. The process for managing escalations was well understood, guidance documents and training had been provided on severity levels and categories. The automated notification system was working and all concerned parties were getting the notifications they needed and had access to customisable dashboards for reporting purposes.


With the SalesForce integration issues proved to be impossible to do, the operational model was adjusted. Instead of having updates to incidents fed into Salesforce the customer service team had to check a web page. Functionally this was identical to the current situation, so it wasn’t new behaviour for them. Ultimately it was felt that the updates to the incidents they were getting with the new system it was a sufficient improvement for this phase.


SWSD provided a searchable database of all incidents and service requests. It was easy to see what incidents had been raised, their status, what was done, by whom, and when.


5 views0 comments

Recent Posts

See All