Xavier

Hi Gerry & co. This might be a misunderstanding of what the intent and purpose of the "Notification bell" is for. Would you be able to elaborate on what your expected use-case is for it? When I handle a ticket, either Service Request or Incident, I put it on hold for a while before I Resolve, to give a customer the chance to provide a further update. If said ticket is updated by the customer, or comes off hold - a notification is generated. I go through these notifications based on oldest first to ensure that I'm handling older content before going to new content. Is this not the correct or expected method to handle support queues to ensure that the oldest doesn't age too far? By only focusing the newer notifications, this prioritises customers that spam for updates and chase relentlessly - forcing down older tickets in the queue to be missed for longer periods of time. UNLESS the staff member clicks the "view more" a few times and works up from the bottom of the list. The request list has lots of arrows for each column for sorting. That's all I feel people want here too. Thanks! Xavier.

Hi, Are there any thoughts or feedback on this? Please and thank you! Xavier.

Good morning, This is a two-in-one, I'm sorry if I should have made two separate topics! 1) Issue: A customer is emailed from the ticket stating xyz. The ticket is then put on hold for x-time with a description and a timeframe specified. The customer then emails back within 5-10 minutes saying, "Thanks!" or similar. This immediately takes the ticket off-hold as "Customer Responded". Impact: Every time this happens, the ticket has to be put back on hold with the previous information either being copy/pasted, or re-written. Solution: Add a button that re-uses the previously applied hold with all the details intact. 2) Issue: An update from a few months ago changed how the date-picker for placing items on hold works. It now only shows the current calendar month unless specifically changing the month shown. With the current state, on the 31st August, there was only one option to pick for putting on hold. Later that day, unless changing the month first. Impact: When it comes to the last week of the month, and a ticket wants to be placed on hold for the following week+, changing the month shown has to be done every time. It's a single press, but with how often it happens, it adds up rapidly. Solution: As no ticket will *ever* be put on hold in the past (the system actively prevents this by blocking out past dates) - the calendar shown should show the current week, and the next x (4?) weeks instead.