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:
   1. Reason: Drop down field to select reason
   2. 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.  Members can comment on this feature in discussions at: https://github.com/orgs/tsanetgit/discussions/30