The ability of an ITSM tool to allow Analysts and Customers to collaborate to resolve a Request is critical to giving good customer service.
Traditionally, Service Desk Manager (SDM) does not allow customers the ability to update other customer tickets via email or web. While in most instances this is the correct and most secure approach to servicing an issue, there are times where teams of Analysts and outside customers need to be able to collaborate on a ticket and resolve the issue as a team. SDM does not allow unlicensed Access Types (customers) the ability to update tickets where they are not the Affected End User. This feature is hard-coded in the SDM system and cannot be overridden via partition rules or form code changes.
I field many complaints about SDM's inability to track dialogue in the Activity Log. Analysts are forced to work outside SDM, typically in their email inbox, to support a ticket and then are expected to copy their final thread to a ticket comment. When they add the comment, they find that they can only update 4000 characters at a time. Email threads can become long during the support dialogue for a ticket. This adds to their frustration when using SDM when they have to create an attachment just to add the email support thread to the ticket.
In SDM, an Analyst (Analyst 1) sends a manual notification to another Analyst (Analyst 2) from a Request. Analyst 2 is able to reply to the manual notification and update the Request successfully. During troubleshooting for the Request Analyst 1 realizes there are other people who must perform tasks or may have ideas on how to solve the problem so Analyst 1 sends another manual notification to Analyst 2 and two other external contacts. Analyst 2 is still able to update the Request via an email reply, but the other external contacts cannot update the Request via an email reply. They receive a cryptic error message that says the are not able to update or create a Request via email.
Analyst 1 can add the external contacts as Stakeholders to the Request, and future notifications are send to the Stakeholders, but those Stakeholders still cannot contribute to the resolution of the Request.
Since SDM has the ability to add Stakeholders to a Request, I propose the idea that adding Stakeholders to a Request should allow those Stakeholders to contribute to the resolution of the Request. Essentially, this temporary "permission" to update a Request becomes a two step process. Stakeholders would only be able to update a Request if they are first added to the Request as Stakeholders by the supporting Analyst/Assignee of the Request. If a previous Stakeholder was not added to a new Request they could not update the Request via a reply to a manual notification. Stakeholders would have to be added to each Request when needed.