Request for input - Integrated Escalation

[paul-tsanet]

Current State: Text based escalation instructions that are sent as part of the request process - Each member has a escalation process defined. A separate critical escalation process exists but has low usage and is not integrated to members systems

Future State: Integrated Escalation – Merge with critical escalations process

1. For Integrated Members
2. Integrates to their escalation process

A separate workgroup exist to work on this feature and includes Cisco, NetApp, Lenovo and Nutanix. This team meets in August and we will provide an update for comment at that time.

[paul-tsanet]

A few ideas based on what most escalation processes are designed around.

• Case Status change - Several systems use the case status to designate a escalated case.
• Note Added that includes the reason for the escalation. Some have more structure so we may need both summary (escalation reason) and description (escalation detail)
• Some have commented that they may want this to be restricted to certain partners. If we keep this specific to the Process form that would be possible as it could be assigned to specific groups

[paul-tsanet]

Also review Severity mapping with lead members. For most Members we find 4 levels
S1 - Critical - This should map to the critical escalation process
S2 - High
S3 - Medium
S4 - Low

[jjgoodson]

HI Paul,

You asked for the customer escalation reasons:

Here is what IBM has now:

Need update/response
Production down
Time to Resolve issue
Diagnostic/Technical Skills
Provided Solution is not working
Increased business impact/deadline
Resource/Meeting coordination
Onsite field engineer
Problem with part(s)
Other 

We also ask the customer two other questions:

How do you want to be contacted - Three options - response to this case, email, phone
Description - regardless of the escalation reason we require a description

Here is our public documentation: https://www.ibm.com/mysupport/s/article/How-to-Escalate-Cases?language=en_US

[paul-tsanet]

Nutanix input:
Priority levels:
https://www.nutanix.com/viewer/content/dam/nutanix/en/resources/support/nutanix-support-quick-reference-guide.pdf

Escalation options:

[paul-tsanet]

Below is what I have seen with Salesforce.

It adds a note and I can see some escalation flag on the case

[paul-tsanet]

Meeting Notes:

Representatives from Cisco, NetApp, IBM, Nutanix, and Lenovo met online to discuss requirements for the integrated escalation process, a new TSANet Connect feature planned for the November release.

Common approach to Escalations:

Integrated escalation is an important step toward making partner collaboration faster, clearer, and easier to operationalize across member systems. The workgroup discussion focused on aligning common process requirements while preserving the flexibility members need to support their own internal workflows.
Members use different internal workflows for escalations and critical account processes. However, the workgroup identified several common elements that can help TSANet Connect support a consistent integrated escalation model.

1. Most Members allow customers to trigger the escalation process from their portal (Escalation Button)
2. Members have different input forms for requests but in general it follows:
   a. Reason: Drop down field to select reason
   b. Detail: Free text field to allow for user input
3. Because each member’s internal process is unique, the integrated escalation trigger should pass core data for each member to map the request into its existing workflow. Examples include creating a new task or related case to track the escalation through closure or flagging the case and adding a manager as a collaborator.
4. Same process should be used for Customers and Partners (single process is best)

Severity / Priority

Today TSANet has a Priority 1-3 with SLA response time measured by initial response at the request record.
The team discussed how members currently use severity and priority. All participating members have adopted a four-level model; most use severity, while a few use priority. The initial proposal is to make Severity the required field and Priority an optional field for members that need it for integrated workflow. Members can use the common response time settings in open groups or define custom values within private groups.
Severity is the required field
• S1 – Critical - Complete outage or security event causing a major business disruption with no viable workaround.
• S2 – High - Significant degradation affecting a critical service or a large group of users, with limited workarounds available.
• S3 – Medium - Service issue with moderate business impact affecting a limited group of users or a non-critical function.
• S4 – Low - Minor issue with limited business impact and an acceptable workaround.
Priority is an optional field to support integrated workflow.
• P1 - Critical
• P2 - High
• P3 - Medium
• P4 – Low

Initial Design Thoughts

The overall design strategy for TSANet Connect is API and middleware simplicity: pass the required data, use lightweight workflow to bond member cases, and send messages between members. Business logic should remain at the endpoint so members can adapt the process to fit their own internal workflows.
Related workflow requirements support expanding the Note object to pass event data that can trigger workflow. The escalation process could follow this model by using a Note Type value to identify escalation-related activity.

1. Add Note Type field with common values (example Escalation)
2. Use Summary to pass Reason
3. Use Description to allow user input
   Unlike standard notes this type would require an acknowledgement (part of phase 2 design)

Web App vs Integrated Members

Requesting an escalation will work the same for all Members
Receiving an escalation is different for WebApp vs Integrated

1. WebApp – sends email to both the receiver management (as defined in the process form and sends manual escalation instructions back to the sender). No acknowledgement is required within the system
2. Integrated – Member workflow uses Note Type = Escalation to trigger the process. Acknowledge with a note: Example (Your case was escalated and manager assigned. For urgent issues call XXXX, reference your case number and ask for duty manager).
3. Current Initial response process for responding to the initial request remains unchanged (SLA monitors for response of Case#, engineer details)

Best Practices Document

Members would benefit from documented best practices. SFDC App can also include a reference flow that can be added to the existing escalation process.

Current Critical Escalations Process

The current separate critical escalation process will be deprecated as the integrated escalation model is developed. More design work is needed, but the target model will communicate the critical account process trigger to members and may require both Severity and Priority fields.

Next Steps

The team will meet again to refine the requirements for the November release.