smart-bonding-partner-api

Smart Bonding Use Cases for Partners

Note This documentation specifically describes use cases for Cisco Partners only. Customer use cases differ. For any questions about customer connections, contact the Smart Bonding support team. For developer API assistance, see Community & Support.

Smart Bonding can be used for these different use case flows:

  1. Case Creation (Partner to Cisco TAC)
  2. Case Update (Partner to Cisco TAC)
  3. Case Closure (Partner closes shadow case)
  4. Case Closure (Cisco TAC closes escalated case)
  5. Case Creation (Cisco TAC to Partner)

Case Creation (Partner to Cisco TAC):

IMPORTANT All Cisco-related cases that end customers open with partners must be sent to Cisco mandatorily. If the partner handles the case resolution, they need to be created as Shadow cases. Otherwise, they are sent as “B2B Escalated” to hand over ownership to Cisco. Cisco recommends automating the Shadow case creation via Smart Bonding to prevent manual error and ensure case volume reports show the correct amounts of partner-handled tickets.

Actors

  • End Customer
  • Partner ITSM
  • Partner Engineer
  • Smart Bonding
  • Cisco TAC CSOne
  • TAC Engineer

Pre-Conditions The system must be in the following state before the start of this use case.

  • There is a working Smart Bonding connection between Partner ITSM and Smart Bonding.
  • The Partner has the appropriate service entitlement information for the End Customer.

Workflow

  1. The End Customer calls the partner for help
  2. The partner opens a case in the Partner ITSM system.
  3. The Partner ITSM system sends a case creation request to Smart Bonding with the following information:
    • The Partner ITSM system’s Smart Bonding connection ID. (This is a static ID unique to each Smart Bonding connection. This ID is sometimes called Smart Bonding Contract and Contract Element.)
    • The customer’s CCO ID and entitlement information
      • Serial number for hardware cases.
      • Contract number and Product ID for software cases.
      • Subscription ID, Smart Account and Virtual Account IDs, or Webex Org ID for subscription product cases.
      • Contract number and any serial number for “sweeps” (Services First Contract) cases.
  • The partner’s contact information: The partner engineer’s name, email address, phone number
  • Case details
    • Partner’s case number,
    • Partner case title, problem description, case notes,
    • Partner’s case status
    • RMA (Return Merchandise Authorization) Ship-To Address, if applicable
    • Attachments, if applicable
  • Case routing/categorization codes: Technology, Sub Technology, and Problem Codes that can be obtained by querying the Smart Bonding TSP API
  • B2B Urgency: Flag to indicate if this is a shadow case or an escalated case. (For PAS
  • Partners, the default is shadow case.)
  1. CSOne creates a TAC case.
  2. CSOne automatically sends back the following information to the Partner ITSM via Smart Bonding:
  • The TAC case number
  • A message to the Partner Engineer acknowledging the creation of the TAC case, providing basic case details like case number, subject, severity, and status, as well as links to the case on Cisco SCM (Support Case Manager) and the TAC Connect Bot
  • A case note with details how to upload attachments

Post conditions The state of the system after this use case ends: A case is created at CSOne. The following case information should be visible on Cisco CSOne's ticket:

  • The Partner ITSM ticket number
  • The Partner Engineer’s name and contact information
  • The case title, problem description, and case notes sent by the Partner ITSM system
  • The partner case activity codes and corresponding date/time stamps (Format YYYY-MM-DD HH:mm:ss, for example: 2023-02-07 15:20:00)

Alternate Flow/Extension

  • If the case is created as a shadow case, the case will remain in the partner’s B2B queue in Cisco CSOne. No engineer will be assigned to work on the case.
  • If, on the other hand, the case is created as an escalated case, Cisco will immediately route the case to the appropriate workgroup or queue. A TAC engineer will then pick up the case. The case status will be set to “CE Pending,” (Cisco Engineer Pending) and this status change will also be sent to the Partner ITSM via Smart Bonding.

Case Update (Partner to Cisco TAC)

Actors

  • End Customer
  • Partner ITSM
  • Partner Engineer
  • Smart Bonding
  • Cisco TAC CSOne
  • TAC Engineer

Pre-Conditions The system must be in the following state before the start of this use case.

  • There is a Partner ITSM case that is Smart Bonded to a Cisco TAC CSOne case.
  • The case is not in a Closed status.

Workflow After the TAC case is created in CSOne, all subsequent updates made to the Case in the partner system need to be sent to the TAC case via Smart Bonding. These updates may include the following:

  • Case notes
  • Case attachments
  • Case Status
  • Case Severity

Third-Party Involvement: When the Partner collaborates with a third-party, the Partner should send the appropriate case updates such as case status changes, notes, and the corresponding third-party details to Cisco. If the case is a shadow case, and the Partner determines that help from Cisco TAC is needed to resolve the Partner case, the Partner Engineer will escalate the case to Cisco TAC (by changing the B2B Urgency field via Smart Bonding). On the CSOne side, the shadow case will become an escalated case, and the case will be routed to the appropriate TAC workgroup or queue. A Cisco TAC engineer will then pick up the case and take ownership. The TAC engineer’s name and contact information will be sent to the Partner ITSM via Smart Bonding. The case status will show “CE Pending”. This status change will also be sent to the Partner ITSM via Smart Bonding. A case can only be escalated once and can never be un-escalated.

After the TAC engineer picks up the TAC case, all subsequent updates made to the TAC Case by the TAC Engineer will be populated to the Partner ITSM case via Smart Bonding. These updates may include Case notes, Case attachments, Case Status, and Case Severity.

Bi-directional updates may flow from CSOne to the Partner ITSM system and vice versa at any time.

Post conditions The state of the system after this use case ends: The tickets in both the Partner ITSM and Cisco TAC CSOne are synchronized and kept up to date. Go to the use case for Case Closure based on Case Visibility (Shadow Case vs. Escalated Case)

Case Closure (Partner closes shadow case)

Actors End Customer

  • Partner ITSM
  • Partner Engineer
  • Smart Bonding
  • Cisco TAC CSOne
  • TAC Engineer

Pre-Conditions The system must be in the following state before the start of this use case:

  • There is a Partner ITSM case that is Smart Bonded to a Cisco TAC CSOne case.
  • The case is not in a Closed status.
  • The case is in a Shadow state, meaning the TAC case has remained in the Partner B2B queue and has not been routed to any TAC queue or workgroup. No TAC engineer has picked up the case. The Partner engineer is solely responsible for resolving the case, and no Cisco assistance has been requested.
  • The Partner Engineer and the end customer have agreed that the case can be closed.

Workflow

  • The Partner engineer closes the case in the Partner ITSM system.
  • The Partner ITSM system sends a Closed status to Cisco TAC CSOne via Smart Bonding.
  • The Partner ITSM system simultaneously sends several fields that are required for CSOne case closure. These fields should be populated by either the Partner Engineer or automatically by the Partner ITSM system:
    • Resolution Code
    • Underlying Cause
    • Complexity
    • Hardware Product ID
    • Software Product ID
    • Resolution Summary note
    • Problem Description note
    • Customer Symptom note
  • Cisco TAC CSOne closes the shadow case

Post conditions The state of the system after this use case ends: The TAC case and Partner case are both closed. The TAC case cannot be reopened after this point. The Smart Bond between the two cases is halted, meaning no case updates can be sent in either direction.

Case Closure (Cisco TAC closes escalated case)

This use case describes TAC closing an escalated case - a case that the partner requested Cisco's help for closure.

Actors

  • End Customer
  • Partner ITSM
  • Partner Engineer
  • Smart Bonding
  • Cisco TAC CSOne
  • TAC Engineer

Pre-Conditions The system must be in the following state before the start of this use case:

  • There is a Partner ITSM case that is Smart Bonded to a Cisco TAC CSOne case.
  • The case is not in a Closed status.
  • The case is in an Escalated state, meaning a TAC engineer has taken ownership of the case.
  • The Partner Engineer and the TAC Engineer have agreed that the case can be closed.

Workflow

  • The TAC engineer sets the TAC case to Closed Pending status. The status change is communicated to the Partner ITSM system via Smart Bonding.
  • The Partner sends a Customer Requested Closure status to TAC CSOne via Smart Bonding.
  • The TAC engineer closes the case.
  • TAC CSOne sends the Closed status, along with Resolution Summary case notes, to the Partner ITSM system via Smart Bonding.
  • The Partner closes their case.

Post conditions The state of the system after this use case ends: The TAC case and Partner case are both closed. The TAC case cannot be reopened after this point. The Smart Bond between the two cases is halted, meaning no case updates can be sent in either direction.

Case Creation (Cisco TAC to Partner)

This use case describes the scenario where an End Customer creates a TAC case in CSOne, but the Partner, not TAC, has the contractual responsibility to address the case first. In this case, TAC redirects the customer to contact the partner for assistance. The Partner can then decide if the case needs to be sent to Cisco as a Shadow Case or an Escalated Case. This use case, therefore, does not require a Smart Bonding connection.

Next