Connection and Service Portal visibility

[Giuseppe Iannacone]

Is there a way to let the impacted/interested user to see the request status in service portal?

as you can see i'm an interested customer but i cannot see the status of the request from the portal

[samwoo]

Hi @Giuseppe Iannacone,

I believe this has been raised a few times before, it's a feature that is of particular interest (and importance) to a lof of Hornbill users so it may be something that Hornbill are looking into if they haven't done so already.

Unfortunately i'm not returning any results when doing a forum search for some reason... (Portal Connections, Connections Portal, Connections OR Portal).

I will let someone from Hornbill confirm.

Thanks,

Samuel

[James Ainsworth]

We do have a change in our backlog to look at this.  There are challenges with this as the the original customer of the incident may have provided information that they do not want to share with co-workers, and as the connections are under the control of the Service Desk, to share that content to other end users without the consent of the original customer, this is likely to cause problems.  

I would be interested to hear feed back about concerns or questions about the sharing of requests without the knowledge of the original requester.

Regards,

James

[Giuseppe Iannacone]

thank you for the reply, we were not considering this aspects. it sounds reasonable. Maybe a "Publish" (like the problem has) option may be usefull to let the service desk decide what to share with interested and impacted people. what do you think about?

[James Ainsworth]

Yes, that is a possibility.  These are the types of ideas that we are considering for that change.  

[Lyonel]

@James Ainsworth In our case, we would not really worry about the visibility... Another option could be to add a simple level of visibility when connections are added to the request. For instance:

• Customer & Connections (would only appear when connections are added to the request - not possible to set as a default)
• Customer
• Team
• Owner

If you do that, then all previously shared information is still hidden from connections. When adding the first connection, a modal could offer to turn the visibility to "Customer & Connections" on and apply retrospectively. Choice is then given to the Service Desk Analyst.

Also, any post set with "Customer" visibility could be upgraded to "Customer & Connections" (but not downgraded once read - as it is the case today).

Anyway... I have quite a few ideas on how to work around the challenges related to information shared previously.

+1 for this change! It is starting to be critical for us... As we are trying to eliminate the emails, we need connections to view requests too.

[samwoo]

1 hour ago, Lyonel said:

Customer & Connections (would only appear when connections are added to the request - not possible to set as a default)

+1 and if we can set this via the BPM, much more of an improvement.

 

1 hour ago, Lyonel said:

+1 for this change! It is starting to be critical for us... As we are trying to eliminate the emails, we need connections to view requests too.

Completely agree, we've already stopped users from emailing and calling to log a request, everyone HAS to log a request via the Portal (except if they cannot or there is a major incident). However other users are unable to see the request if they are a connection (or even if they are in the same team as the customer, but this is another thing entirely)

Thanks,

Samuel

[James Ainsworth]

Hi @Lyonel @samwoo

We still have this change in the backlog, but it has not reached our 90 day development queue yet.

I would still like to ask again about visibility and sharing of data.  Putting yourself in the shoes of an end user, if you raised a request with a support desk you may do so with the thought that your communication is between you and the support desk. You may enter information that you may not want or expect to be shared with your co-workers.  Despite the desire for the Service Desk to share this information, it may not be the desire of the end user to have their information shared without their knowing. 

I am looking at an approach similar to the publishing of a Problem or Known Error where you can add a customer facing description and publish an Incident which could then be displayed to Connections.  My feeling is that it would need to exclude any information about the original customer.   Then there is the Timeline.  A customer may need to know that their updates on the Timeline may be visible to their co-workers (or contacts from other companies if you are doing external support)

I would be interested to know what are the limitations/challenges that make the use of a published Problem in these scenarios not workable?

Please continue with your feedback which will help provide more information for the planned change as it progresses.

Regards,

James

[Lyonel]

@James Ainsworth I will speak about my personal case here (which is probably "unique" to my company).

We implemented Hornbill following ITIL best practices & recommended processes. As such, for some incidents or service requests (because Changes are not visible via the service portal) more than 1 person could be involved. When such situation happens, there are no "sensitive data". Just an issue to fix ASAP. 

I totally understand you standpoint and agree with it. But in our case, it would just not happen as we (service desk analysts) control the connections and all our customers are internal people (no external customers) therefore even in the event of a mistake, it would not be a major problem.

In our case, the published problem mechanism works well but because we stick to ITIL, problems are only logged once the same incident happened at least twice. And this rarely happens (after 18 months of Hornbill we only have 13 problems logged). A typical scenario is:

--- EMAIL RECEIVED / REQUEST LOGGED ---

• A customer / user logs a ticket because a particular service is not working properly, via email (80% of the time)
• That customer copies a few of his colleagues who also have the same problem
• We fix the issue and use the service portal to publish updates and let them know how we are progressing
• Customer / user confirms the fix by clicking "It's working"

--- END OF REQUEST ---

During the resolution of the incident, all parties (customer + connections) would like to be kept up to date with the progress considering it is impacting their daily job. If we had to create a problem on top of the already existing incident, this would generate:

• Great confusion for users - which ticket should I look at? Why do I have 2 tickets for the same problem?
• Great confusion for analysts - which request should I update / work on?
• Not fully respecting ITIL (unless 2 or more customers log requests for the exact same issue => quite rare in our case | they rely on emails CC-ing people)
• Extra admin work for IT staff
• Reporting / Data analysis would be trickier as we would need to remove "duplicates" manually.

In my opinion, the real disconnect at the moment is as follow:

• We are trying very hard to NOT work so much with emails but get people to log onto the service portal and follow the progress from there (and provide updates & feedback, read FAQs & bulletins, etc.)
• Connections cannot see the request via the portal
• Customer has no way of sharing the request except via screenshots or "print" functionality of the browser (NOT the built in functionality available in Service Desk - wiki)
• Customer does not receive a nicely formatted email when we post an update on the timeline
• Connections are not notified they are added to a request
• We therefore only have 1 option to update the users (incl. connections) about our progress: e-mail

Again, this is our personal situation and I very well understand it is specific to us. But at least you now have, I hope, a clearer picture of our challenges  If not, we can always have a chat over the phone.

In terms of technical solutions, why not had a few options for the customer on the request's screen such as:

• When connections are added, the customer has a choice to make all posts with visibility "customer" to "customer + connections" [that could be translated to "me only" & "public"]. The customer would then have the choice to make the whole timeline public or remain "private" (via a modal with simple / clear description of the process and its risks)
• Customer, when posting an update would then have a choice of visibility (like we do in Service Desk): "me only" or "public"
• Connections could post updates but they would be "public" by default

Basically, why not move the decision from the Service Desk staff to the customer? But still allow connections to be added and view the request?

And why not offer your customers (like myself) the choice via a setting to "allow connections to see requests their associated with" (giving the service desk full control) and another setting "allow customer to select visibility of posts" adding an extra layer, more granular, where the customer is in control?

If you use facebook messenger (and probably other social media tools) when you add a new person to an existing conversation you get a warning saying that this new person will see all previous updates... That's my inspiration for this idea.

Sorry about the long post, I just hope it gives you more context, understanding and ideas on how to progress this topic. 

 

[Giuseppe Iannacone]

@James Ainsworth

we have more or less the same challeges described by @Lyonel, while I do not agree on moving the choice to the customer there might be an escape using a "Global issue" tag that may change the behaviour of the timeline, hiding everything but the update provided by Service Desk agent with the approach "customer" "team" or "public.

marking a ticket as a "global issue" the information had with the customer might remain private between SD and the customer, but the connection will receive a reasonable feedback on the issue status.

[James Ainsworth]

@Lyonel

Thanks for your post.  I really enjoy seeing this type of insight.  It certainly helps to make things clear and helps with defining the requirements around this feature.  And thanks @Giuseppefor adding to it.

There are some good suggestions that might allow us to progress this a bit further.  I may look to ease this in with a few separate small changes.  I will keep this post updated with any progress made to this change.  It is currently in our backlog and not in our development queue, but I will continue to review this.

Regards,

James