Keith

From my perspective, as the customer, I want to be able to follow up on the issue to find out what the status is etc. Again using the example issue that started this conversation, what is the current status of the issue? When can I expect a resolution? etc. From your perspective as S1, you have told me what the issue is and whats causing the defect and that you have handed this over to your dev team. You assume this is enough. However, I believe as the service provider you should be keeping me, the customer, regularly updated on the issue. What benefit do I get from checking the published defects list currently? I know its a defect because you have told me that when you marked my request as resolved. I have no need to say I am affected because you know I am as you logged the problem on my behalf. What I really need to know is what is the status, what priority has my issue been given, has work begun on resolving it and what is the expected timeline for resolution. I envisaged you may need further examples from me or steps to recreate the issue. If this is never the case then OK. By portal I presume you mean the published defects as I now have no request I can follow. In this specific case, my problem isn't even being reported in the published defects. Someone in the process (presumably now at S2) should be able to advise me where my issue stands in terms of priority and provide an estimated timeline. As it is currently, my issue is like a submarine which has taken a deep dive and I'll only see it again when it surfaces, assuming I'm looking out for it when it does.

Thanks @Aaron Summers no idea how those last three got there? Please ignore them.

@Victor I totally understand how you're operating in terms of the two-stage approach and the handoff to the development team. In resolving the incident I am provided with a problem reference which, in theory, I can now track online in the problem tracker (though again in this instance I can still not see it). I can also see it referenced in the release notes of a new release. But, I now have no open dialogue on the problem. There is no channel of communication between me and the development team should they or I need further input or examples. The onus is now clearly on me, the customer, to monitor and track the situation and essentially I have no means to provide updates on the situation to my customer other than to advise its still in your development queue. I know your taking steps to try and improve the situation and I understand why you work the way you do. I'm just trying to illustrate this from a customer perspective.

@Victor thanks for the explanation. I fully understand what you're doing (and possibly why). My point though was that from a "customer" perspective the issue is not resolved. In simple terms the customer has an issue that needs fixing, they don't care who needs to fix it, they just want the system to work correctly. Using your approach I should close my incident with my Leica side customer because I and my support team can't resolve the issue. So, I'd mark my request as resolved and open a request with you. Clearly, this doesn't help the "real" customer. Possibly a better solution would be for you to keep your incident open until a full resolution is forthcoming (this is a defect, not a development request). The closure of your problem/change request could close the linked incident automatically. I get that you won't want to do this as you don't want any overhead managing these incidents or impact on your SLA's. BTW the request that triggered this discussion is still not solved and is not on your published defects list. In the meantime, the incident raised by "my" customer is still open on our side

I apologize for the lack of input on this topic so far, unfortunately, real life is getting in the way. I have quite a few concerns about the changes to the service portal and the input to the user community. I feel that our current service portal looks far more professional than the proposed "My Services" view. Current Portal... Current "My Services"... Sorry but in my opinion, this does not look great in comparison to above. Some of my issues are as follows: 1: Remove Hornbill branding and replace with ours. - Our users know nothing of Hornbill, our service desk is branded as "The Leica Support Hub" 2: The header area is too large. There is a lot of wasted space above the above the search box and I think the test of "My Services" is too large. 3: Too much wasted space at the sides of the screens. I personally don't like the "Windowed" look and would like to play with the background image to see how I can improve the look. 4: Again, too much wasted space in this area in my opinion. There is such a lot of space at the top of the screen before we get to the services themselves. 5: The texts seem to be using a different colour to that of the current service portal. Also lots of wasted space again. We should also have the option to show descriptions of the services. I personally prefer the bulletin at the top but it needs to be very narrow. Perhaps more of a ticker tape effect would be better. Sorry to sound so negative. Keith

Thanks for considering @Gerry, I appreciate these things are sometimes complicated by other integrations. Anything you can do to make access more readily available on a very limited basis would be enormously helpful to me and as you say will ultimately help drive usage of your applications. Keith

Many thanks @Patrick Bolger . May take you up on the offer of a chat in the future when time allows.

Thanks @Dan Munns , really appreciate the input. Sounds like you had a very positive experience with SDI and I have to say from what I've been able to ascertain so far they are my preference.

Hi @Paul Davis , apologies for the delayed response. I was sure I had replied but clearly not I appreciate you and the team reviewing your processes and trying to affect change for the better of your customer base. I just want to make it clear that in my request for visibility I was not pushing for a resolution timeframe or prioritization within your development queue. My concern was that incidents raised which relate to a product defect were being marked as resolved when if fact no "real" resolution to my issue had been provided. At this point of resolution, I lost visibility of the issue and ability to correspond with Hornbill on the topic. Hopefully, the changes being implemented (are they in place yet) will have a positive effect and provide more incite and status as to the current state of my issues. Regards Keith

Hi @Keith Stevenson any update on you providing a suitable solution to this?

OK Thanks @Keith Stevenson It did return results on a small 500 sample but times out when running for full dataset as advised. Will await further feedback

Thanks @Lyonel looks like you've come to my rescue again. This is exactly why this forum is a great place to be. Haven't tried it just yet but will give it a go later today.

Hi, Wonder if someone can explain how to join the Requests table with the associated tasks so that I can report on them. i.e. Gather a list of requests which contained a specific task with a specific outcome. Thanks!

So was I @Steven Boardman - better late than never

+1 - I'm sure I've raised this before too. We also struggle with managing the vast array of measures etc. Some form of categorisation or tagging would be very helpful.

+1

Thanks, @Lyonel for the suggestion to use the demo. However, the ability to evaluate would be so much more powerful with our own data/resources etc in the system.

@Gerry @AbdiH Not sure where to raise this so please move as appropriate. I am at a point where I would like to re-evaluate the Project Manager app and this reminds me of something I wanted to suggest. Many of us are evangelists for Hornbill within our own organizations and I think it would be beneficial if each organization/admin was given a free license for each of your apps in order to continue to evaluate them. This would allow us to keep abreast of app developments until such a time as appropriate for our adoption (as I'm hoping is the case for Project Manager). Could you give this some thought as to whether this would be something you would be prepared to facilitate and if so to what extent. If this isn't something that is forthcoming soon can you advise the best approach for me to evaluate Project Manager? Thanks Keith

Thanks for considering @James Ainsworth

Hi @James Ainsworth Thats a shame! The reason for us using these vs the Advanced Analytic Dashboards is their ability to drill into the data. We have a stand up daily management meeting around a large wall mounted touchscreen which we use interactively to review and dive into detail. I can't do any form of drill down on any other type of reporting in Hornbill. I can, and do use Power BI for some of this kind of reporting but the data is not real time. As a manager I find myself in the dashboards also on my own screens and would find it hugely beneficial for them to auto update in the way that the request list does. Regards Keith

OK, Thanks for the info @TrevorKillick would be good to get an example @Steve Goldthorpe if possible. Are there any other methods of creating Requests in Hornbill other than an email with associated routing rules etc? Thanks! Keith

@TrevorKillick Any news on further Flow integration? I'm also looking for a way to create a request from Flow. Is this possible or likely to be in the future? Regards Keith

I am considering joining either the SDI or itSMF. Can anyone offer any advice on which one would be more beneficial?

@James Ainsworth any progress my dashboards auto-refreshing. FYI I use these on a large touchscreen in the office and it, unfortunately, they are acting as essentially static dashboards until someone walks over and manually refreshes.

That's fine as an alternate approach to email. But many users will not have a company mobile where this can be provisioned.