Acceptto Case workflow [INTERNAL]

Follow
    Applies to:
  • Arculix
Deployment model:
  • Cloud
  • Version Affected:  ALL

    Description:  

    When dealing with Acceptto and Acrulix support cases, we need to follow a proper workflow. This is the current workflow but is subject to changes as we get trained up on using and debugging the product without the assistance of the Engineering/Development Team.

     

    Cause:  

    We need to start working Acceptto/Arculix cases sooner than later and relieve the burden on the Engineering/Development Team so they can focus on building and bettering the product.

     

    Resolution:  

    L1's make first contact (will eventually ask a few questions during the transition) and push to L2/3 queue (Use the macro as the L1's do today), we L2/3's digest the case, if we can help we try to resolve the issue, if not:

    1. if it's during normal business hours we can assign to the resource directly and add Mark Sabahi in the CC for the case.
    2. if it's after hours we attempt to work the call and if we find that it is an actual urgent issue, call our on-call. Our on-call will review and qualify if it is actually urgent, if yes, we try to solve it. If we can't, our on-call will call the resource listed under the product. if we can't get a hold of said person we call Mark Sabahi.

    ***Acceptto cases have internal notes with the list of people to call in order, based on the area of the product.

     

    We also follow along with the ticket to make sure it's being worked and we shadow calls/troubleshooting  sessions, and make sure the resolution is documented in a private note prior to closing out the case.

     

    Once a ticket closes, we need to start creating KB articles on the different issues so we can keep sharing that knowledge around the team.

     

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.