Trigger RESOLVED events when Create Incidents as CLOSED

Idea created by Chad Brown on Jul 10, 2018
    New Idea

    We noticed issues with the application when creating incidents in a CLOSED state. The general use of this is when a customer contacts the Service Desk via phone, and the Service Desk creates the incident on the call in a CLOSED state. We did not realize the "Created as Closed" incidents bypass all Resolved functions. Meaning:


    • No person is listed in the “RESOLVED BY” field
    • There is no “RESOLUTION CODE”
    • There is no “RESOLUTION”
    • A SURVEY is not generated


    Each of these carries downstream impacts that affect metrics, perception from the customer, and the ability to transfer knowledge.


    1. RESOLVED BY: Without a person listed in the Resolved by field, these incidents become lost when doing weekly, monthly, or annual reports of incidents Resolved by each person on the Service Desk.
      1. The incidents still show as Created at during a time frame; so if looking at incidents Created from 1 July to 10 July, and then looking at incidents Resolved in the same time frame to determine you have an invisible delta.
      2. Resolved incidents auto-close 24 hours later, and by the application; so CLOSED BY searches are equally unreliable.
    2. RESOLUTION CODE: Without a resolution code, we are unable to draw metrics on the TYPES of resolutions being applied.
      1. Did we get an uptick in "Information Provided" resolutions during a week? If so, what information should we get sent out by IT Communications to address this?
      2. Did we see a lot of "Duplicate" tickets? If so, which business unit so we can schedule training on how to search for all open incidents in your department to avoid doubling or tripling them?
    3. RESOLUTION: Without a RESOLUTION, there is no telling what the Fix was. When another person calls back, or the same person, there is no way to query previous incidents for the fix.
      1. As a subnote, it also means the analyst is NOT PROMPTED to create a Solution from what they did, preventing the Knowledge Base from expanding.
    4. SURVEY: The application generates SURVEYS when the incident is RESOLVED. By creating incidents in a CLOSED state, and bypassing the RESOLVED state, the customer never receives the survey invite.
      1. This causes fewer "satisfied" customers to receive the opportunity to provide feedback. After all, when you call and someone fixes the issue in 30 seconds; you are more likely to have a positive experience than if your incident took three weeks of research and a Change and Release to resolve.
      2. In addition to a skewed metric, where only people that don't get immediate service are queried, there isn't feedback on the speed or efficiency of the IT groups.


    I have entered this as a Feature request, but given there are so many negative downstream impacts from this feature of the application, we consider a defect and are now having to train people away from Creating as Closed.


    And that has its own downstream impact, look at our First Touch Resolution go through the floor.


    What problem will this feature solve?:
    It will address problems with the way the application treats "Created as Closed" as blackholes of data in the application. If the choice is try and maintain a good First Touch Resolution; or provide a well rounded incident (with Resolution Code, Resolution, Resolved by entity, a possible solution, and customer feedback) - the choice is obvious, abandon "created as closed."