any Idea for this question, the customer is asking and insist on a way to show ticket details from DWP (link, button or even a form) that let end-user click on it from DWP and show ticket details
I can imagine something like....
In the DWP Catalog Warkflow you can do Add Activity Log. If you do this after you create a Ticket (e.g. incident) you should already know the incident number. So you can build an URL to open that itcket (in midtier or smartit) and put it as activity log into the DWP Request.
Then the requester should be able to see such link in the comment of dwp request.
I have implemented something similar t this by putting in the Comment section of DWP all the details customer requested but they said that it's not considering to use the comment section for this and they have asked me to find a way like put a clickable button redirect end-user to ticket details or put the URL directly in somewhere apart from the comment.
but what I need to ask you about is how can I build the URL that opens directly to the ticket details by knowing this is the ticket number of the raised service request number, how can i achieve this URL.
With the newer licensing contracts, read only access isn't available so you would need to give your end users paid licenses. Would they want that?
Yes, they want that.
more to that, I believe that can see particular information related to their read license.
I believe that can see particular information related to their read license.
Exactly not, there is no more read license in the new world (SmartIT) and the wish "I want to read the backend tickets too" quickly costs many 100k $ or € or . Good for BMC, but really useful for the customer ?
I would rather get the customer to position themselves more clearly and explain what exactly they miss in DWP. Afterwards you can think about how to solve this. Usually the customer has no idea about the technical possibilities and thinks about solutions with a certain amount of half-knowledge instead of describing his problem.
actually they need to read the information about the tickets in Mid-Tier not in Smart-IT, as they still don't use the Smart-IT and using Mid-Tier.
All That you think about to explain to the customer was explained to them besides many possible solutions, but they need that to be possible, as they were using the requester console in the Mid-Tier and now they have implemented only DWP. in the requester console as you know, they can let the end-users see all the tickets details so they need the same after implementing DWP and it's not logical to End-user thinking that he/she was accessing the details of the ticket and now implement new Console without Let them access the details and this is the customer focal point and main point of the discussion happening with the Customer.
Interestingly, our customers were very satisfied with the changeover to a modern UI. After a short period of getting used to it, there is almost no missing information from the request. Only the common view on tickets is not so well implemented for large organizations.
I have to ask again, which information exactly do your customers miss? There are many good solutions.
they missed the Ticket ID (Incident ID or Change ID), Approval Details if it's a change and pending for approval, Status, Assignee, Category( 3 tiers), Resolution.
1 of 1 people found this helpful
Even if it may seem that way, I don't want to talk you out of your solution My team and I invest a lot of time in our company to create exactly this transition between customer/user and support area and I recognize our customers in your scenario.
- The customers have a TicketID, for which they still need an internal ID of the support backend. With us it was just habit from the old world. What happens if a process requires two or more backend tickets?
- Categories of the backendtickets? These of course have the focus on support aspects like automatic ticket routing, SLM, internal reporting and escalations. For the fullfillment on the customer side it might be interesting, but it should not be the customers concern. The requests themselves can be categorized from the customer's perspective.
- Solutions can be transferred as workinfo. This is how it is designed OOB.
- Assignee? Of course every end customer wants to know his personal assignee. Preferably with a direct dial telephone number and e-mail address But can the support team work efficiently? Surely not, because every issue is priority 1 for the user and the user will force a solution. If someone pushes forward, at least one must wait longer! DWP has a communication option, after a few weeks this is often sufficient. Every support employee likes to be the hero and to be praised directly. But it is damn expensive for the support - time, resources and therefore money.
Ok, are only a few thoughts and experiences of a quality manager on this classic topic. You are the expert there on site and you will find the best solution. Just don't try to build around everything, it will pay off sometime during an upgrade
This change process is not an IT problem.
Thank you Stefan for your response, appreciate your time in providing this
I have read all your responses regarding each field, and this has been said to my Customer before and they didn't convince with that response. the exact same response you provide in your comment has been said before from my side to the customer and they still need this information to be showing to end-users.
- the response of Backend ticket that what if the request has multiple backend ticket, the customer said that they don't do that and each request has only one ticket.
- the response for categories, the customer said they need it as it's referred to internal department they have mapped with some information related to the customer for their business operation.
- even, I have developed all this information to be shown in the comment section (Work Info), but they refused as they said the end-users can be confused between that and the comment that came from Supporter.
all this possible responses and solutions have been provided to my Customer as we are going in discussion around one month in this point and nothing has been achieved their business needs
1 of 1 people found this helpful
Ok, I don't know if this will make them happy or not.
but I think you could do a quick launch URL to a Web Report that shows them a list of their tickets with this information.
Been a long time since I did a quick launch url to a web report...but I think it worked in the past.
Time to think out of the box. Unless you want to buy a lot of licenses for the end users.
Thank you so much for the idea, it's good option to include and discuss it with the Customer.
is there are any way to make this web report for each End-user including only their Submitted tickets.
what I mean is the Web report for as an end-user when I click on quick launch will include my submitted tickets different from another end-user if he/she click on same Web Report.
I think so,
- In Smart Reporting you can control it via Access Filter.
- In BIRT I mean, you will be given the Login ID in the http post. So it should also be possible there.