"Me too" for incidents

[Smurfy]

Hi
I have mentioned this before but I worded the title very poorly so I think I caused confusion.

I would like a way to "publish" a ongoing (a major outage) a bit like you can with problem where a user can then can click a "me too" to register they have an issue too.

Ideally this would not only make them make them a connection of the "master" incident but also I would love it more if would create another ticket (based on the master info) but them as the user.

Maybe I'm going to deep but if we could link the me too button to a PCF we could set it to ask not just who but also for their machine name or another question we want depending on the major incident scenario.

Laura

[samwoo]

+1 for extending the "Me Too" functionality

[HGrigsby]

+ 1 for me too please

[Sam P]

+1 for me too for me too please 
We are not currently using Problem Management but would love for people to be able to add themselves to our MI's

[Guest Paul Alexander]

+1 for this please

[Berto2002]

+1

[Steve Giller]

On 3/17/2022 at 10:41 AM, Smurfy said:

would like a way to "publish" a ongoing (a major outage) a bit like you can with problem

I think the issue here is that a major outage is not an Incident - stealing a nice quote:
 

Quote

At its most basic definition, an incident is a singular, independent event.

If you're having numerous customers clicking "Me Too" then it is neither singular nor independent and therefore, by definition, not an Incident.
The individually logged Incidents are grouped under a Problem and the Problem Record has a "Me Too" option to streamline this process.

[Guest Paul Alexander]

I agree that, from an 'official ITIL' point of view that's correct, but we're not set up to use Problem Management at the moment so having a mechanism to be able to do what @Smurfy suggested would be helpful for us.

[Smurfy]

We do use problem but not initially
So for an example. 
We have lost access to our internet - We drop everything and are investigating the issue. 

In that period of time we will see many people call us to say "I cant get onto the internet"
We need to record all of those and link them to our master (or major if it's critical) record. That way as soon as we restore the service we can notify all our users who reported an issue and we are able to see the impact via reporting.
To save our Service Desk being swamped and having to log individual tickets I would like the me too function so

1. The user can let us know they are affected without having to use our Service Desk analyst resources and swamp them with calls
2. Ideally that it will log an incident at the same time and link it to the master / major

15 years  or so ago we used Axios Assyst and whilst it didn't have a self-service it did have a "major inc" box.
When we created a ticket and ticked the major inc tick box it made that ticket available in a list that we could just click on and add the next users employee number. It would then create a copy incident, with that user, and link it to the major.

I guess what I am asking for is something similar to that expect that we can make it available on Self service.

[Steve Giller]

1 hour ago, Smurfy said:

We need to record all of those and link them to our master (or major if it's critical) record

Just make your Master a Problem, and you have a "Me Too" button.

[Smurfy]

We do problem differently Steve. We don't make major outages problems so it would not work for us. 

[Steve Giller]

I don't have any say in what is accepted as a change to the Product, so I'd have to leave any comments on that to other Hornbill staff, but as far as current functionality goes everything you want to do is already there.
You can replicate, and improve upon the "Major Incident checkbox" with a Custom Button that raises the MI (as a PM so you have the "Me Too" function) and does whatever else you need it to in the attached Workflow.

[Berto2002]

This is a classic where HB are torn between designing something that meets a framework and something that does what customers want. I venture, though, that the code to implement "me too" to work for Incidents the way it does (does it, not tried it) for Problems would not be a big deal; and many customers seem to want to work that way.

I had this today as a trigger for how keen apps people are for it:

In an operational environment, the fact is when "the proverbial" hits the fan, the last thing any of us want is ticket admin; the best we can do is get someone to log "any ticket" of any kind so there are things we are keen for the product to provide which allow that flexibility; and reduce our ticket burden.

I don't really agree with your definition of Incident. The classic is "An unplanned interruption to an IT Service or reduction in the quality of an IT service". One interruption can affect hundreds of people and we don't need or want a ticket for them all. We present such an occurrence as a single "Major Incident" IN reference and use it to manage the outage. What we seek is only a way for a Customer to see there is an active and known "unplanned interruption to an IT Service or reduction in the quality of an IT service" and to put a vote against it. Should we really need to log a Problem ticket in parallel with an MI, publish it to users and and gather our stats on that instead of the IN itself?

[BobbyB]

We actually just received a request this week for this option.  But sorry Steve I'll have to disagree with your definition of an Incident/Problem.  Anything that is 'broken', 'faulty', etc. will be an Incident.  A fault with a high use application will cause numerous calls into a helpdesk/service desk.  So we are talking about a high number of singular events.  A 'master' Incident is normally used for these situations with subsequent customer calls added as 'Impacted' onto the master Incident.  That master Incident is then resolved when it is either fixed or a workaround is in place.  After that point a Problem record can be opened.  Problem records are used to find the root cause of Incidents and are normally opened when you ask the question 'so what actually caused that issue' and the answer is 'we don't know'.  Once the Root Cause is determined then it becomes a Known Error, which can be either used to fix incidents or workaround them.  Finances normally come into force on some Known Errors, easier to reboot a server once a week then to replace costly main circuit boards or upgrade software taking hundreds of hours.

So to go back to the original question here, yes having the means for customers to 'Impact' themselves onto a master Incident would be of great benefit as that then can show the true impact of the Incident on the organisation.

[Estie]

This might be useful:

The Wiki about Workarounds and Known Errors advises:

Known Errors

It is not necessary to raise a Problem record in circumstances where it is known that a permanent fix is not available. In such cases a Known Error record can be raised containing the workaround information. This is more efficient and removes the steps associated with raising a problem record first and then having to promote this to a known error. Any user with the Problem Management User role will be able to raise a Known Error.

This page suggests that Known Errors can also have the 'Me too option': https://wiki.hornbill.com/index.php?title=Publish_Action_Item

I am not quite sure how to raise the known error yet.

 

[Berto2002]

I would like to bring this item back to the table. There was some agreement among the customers at the HUG23 that we should have some way for customers to be told about and instantly state they are affected by an existing Incident rather than us have to publish Problems or Known Errors for them to use the "me too" option. I can see how Hornbill use the current feature in an application support environment where incidents get assessed and may or may not appear as defects weeks later for people to vote-up. But many of us work in Infra and Ops and we need to go from IN logged to announcing it to our customers within minutes. This is also unrelated to whether or not there is a Known Error (which may follow). This is a here-and-now immediate service availability notification with some additional functions.

I request something like:

• Two-click feature or workflow node to present notification of the IN to the Subscribed users in the portal; perhaps this is a fast-path access to an Announcement on the Service by adding a new Action Icon. Feature can be activated by permitted person which we'd want calibrated to include senior analysts at Service Desk
  • First click to activate a capture box in which we can enter the exact text to be presented; typically like "Users seeing error xxxxx when logging in" and a default, "Click if you are Impacted"
  • Second click to publish it
• All Subscribed users can see it if they go to the portal.
• Users have two options:
  • "I am Impacted"
  • "I am Impacted and keep me updated"
• "I am affected" adds the user as an "Impacted" connection
• "I am affected and keep me updated" adds as a connection as above with a flag to receive notifications flagged for "Customer"
• One click removal of the portal text whenever required and by default on Resolution
• Does NOT give access to see the Request itself or provide a link; this is announcements only

Reasons to have this feature:

• Reduce the number of logged tickets, saving customers and analysts time
• Better gathering of the true extent of the impact of an incident; users are far more likely to click a button than log a ticket
• Fast notifications to users of major incidents/outages

My main requirement is that I have been asked for find the 'true' rather than 'assumed' impact of incidents. That is derived from the people directly affected at that time by that service. It is always only a subset of the known users; most people don't use all apps all the time and another group can go and do something else if one is down. We need to have a way of giving the business a very easy way to report how bad an outage is for them and reporting the result so they can encourage their people to use it. "It's two clicks (one to the portal URL and one to click impacted) for any user to declare they were impacted and this is how many people clicked the button to say it hurt them: X"

@Estie @Smurfy @samwoo @HGrigsby @Sam P @BobbyB. Comments?

[Berto2002]

Bump...

[Berto2002]

@Steve Giller noticed this is not tagged as enhancement. Could you please?