@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.