Daniel LaCoste

Hi Lisa Kelly,

Just to clarify, like many other replies in this feedback thread, Kav Chatha is stating that the loss of text when swapping between public & private modes is frustrating, time consuming, and a confusing UX from earlier versions of Zendesk. 

It amazes me that the feedback in this thread and other threads is crystal clear, and yet Zendesk themselves cannot understand our problem or interpret our feedback correctly..

if Zendesk continues to make changes just for the sake of making changes with no admission of user feedback, then Zendesk will continue to turn a base of promoters, the folks who care enough to come to these forums and share candid feedback, into detractors. If a Zendesk competitor that listens to user feedback appeared today, we would no longer be in this forum leaving replies on threads that persist for years: example 1, example 2, example 3

Dear Zendesk Product Managers, please take our feedback seriously and stop trying to workaround us with faux product "fixes" — Draft mode does not fix this change, and I urge you to revisit the original functionality.

This change clearly misconstrues the original issue raised by your customers.

Your post states:

an easier and more efficient way to draft messages, without requiring them to copy and paste from an Internal note.

An easier and efficient way to draft messages is to reintroduce the original functionality: let users simply toggle the Public & Private mode without clearing the input field so that we are not "required to copy and paste". Remember: Zendesk introduced this "requirement" themselves — in 2022 this suddenly became an unnecessary "requirement"!

Allowing admins to select the default state for their agents is helpful — but the "Draft" mode does not maintain state across tickets, so an agent must enable it for every new ticket. This introduces needless mode switching for every ticket, another Zendesk "requirement".

Agents understand that Private mode is a visually distinct function — the entire input field turns yellow! Toggling a tiny "Draft" icon does not clearly convey purpose, and becomes a confusing blocker if you accidentally leave "Draft mode" enabled when you click Submit. The Internal note and Draft mode use the same icon, too — if they're meant to be distinct functions, they should have different iconography:

 

If you genuinely want to improve the experience, I suggest revisiting the original feedback post.

Zendesk used to clearly label "Solved" tickets differently from "Closed" tickets within the View interface. Now, Views display "Solved" tags (with the same label color AND title) for both "Solved" and "Closed" tickets:

Now, both labels for #96568 and #95440 are visually the same, but the underlying tickets are in two different states: the former is "Solved" and mutable, whereas the latter is "Closed" and immutable. The only visual indicator for tickets in different states is the box icon, which is less obvious, and not explicitly clear (especially for new Zendesk users).

Zendesk should revert the mono-Solved-label and clearly disambiguate between Solved & Closed states. 

Hello,

If i create a view with the following settings:

"Tickets must meet all of these conditions to appear in the view" where the only condition is "Group Is Support", the results are 10,082 tickets in the "Preview" — however, when I use Zendesk search for simply "group:Support", there are 28,011 ticket results.

How come there is such a large discrepancy between a view and a search that should result in the same amount of tickets? 

Thanks!

+1 to this thread — the old Zendesk functionality (maintaining the drafted message between Internal and Public replies) was much easier to use for all of the reasons mentioned above by other users.

Hopefully this thread is a reminder to Zendesk PMs to conduct a modicum of user research before making clumsy changes to common workflows.