Home› Analyst Portal

how to handle long time paused tickets?

Silas_SulserSilas_Sulser Customer Advanced IT Monkey ✭✭✭
in Analyst Portal

Hi folks

We've got a lot of user-offboarding-tickets where we have to wait for some actions, sometimes about months.

Example 1: user leaves company, user should be disabled right now, but mailbox and user can only be deleted in one or two months, because they are expecting some important mails on this mailbox.

How do you handle such tickets?

These tickets are assigned to our analysts over months, and it gets harder and harder to keep an overview about all tickets where they are assigned to.

Is it possible to put them on hold and in a seperate analyst pool with a scheduled reminder or something like that?

Many thanks and best regards

Silas




Best Answer

Answers

  • Silas_SulserSilas_Sulser Customer Advanced IT Monkey ✭✭✭

    Thanks for your approach Brian, thats a good solution!

    I've still got a question to your second part: Is that only possible when using activities?

  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    Use Case example we have.
    User is placed on legal hold. 
    We do not want to place a service request on hold for the entire legal process. So what we do in the Service request to start the hold the last activity is to fire off a run book. The run book creates a SharePoint list entry. We then use SharePoint at the record of authority of legal hold status. We have a analyst review the site on a scheduled bases. If a hold has expired they update the SharePoint list after submitting a SR to remove the hold. Someday I am hoping to automate it more that the hold date end passing will auto create the removal SR. But the catch 22 on that is sometimes the legal end date changes. HTH

    For the Holding queue what I was referring to is, Tier 1 Tier 2 support groups. Add another for Tier 10 or what ever name you want. (Mine is called workflow automation) 
    I do not have any analyst mapped via tier mapping to this support group. Then when you have a long standing ticket park is in this support group until it is ready for review. 

    I will note I would recommend the SharePoint workflow more so as it keeps your long standing tickets out of the live database. My goal is to always keep the SCSM DB thin due to the number of workflows. 
  • Adrian_PaechAdrian_Paech Customer Advanced IT Monkey ✭✭✭
    We use "required by" date for our SLOs in SR.
    Essentially, we use the specified "required by" date (e.g. When the user requested to have the work done by when filling out the request offering) as the SLO target date (+ 1 day) and then, if for some reason the job is delayed, we simply push back the date and the slo automatically adjusts. Have to say it works really well.
    Just another idea :)
    Obvously not appropriate for Incidents though..
  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited September 2017
    Just wanted to throw out another idea -

    In the termination workflow, you execute all the runbooks necessary to handle the "right now." Disable in AD, move to some Organizational Unit, whatever you do, etc, etc. However you have a single runbook that writes/sets some kind of flag on the user record in Active Directory. Your request is completed and everything is done...for now. Then with SCO/SMA you have a daily running job that looks for all users with said flag. When found, you perform a new set of actions such as creating a new request, with its own workflow, and its own automation. You could arguably re-activate the request, add new activities to it, or create a wholly new request and then relate it to the original.

    This allows a pause of sorts, without any real bearing on SCSM understanding said pause but instead leaving it to your automation engines.
Sign In or Register to comment.