Neil Lillemark

ok - I guess I was just getting a little ahead of myself.

Offering a "roadmap" page that lists which features are being worked on and their ETA for completion would be useful for a SaaS product like Zendesk.  Your GDPR example is a good point on how priorities change - I understand that such things happen, but I still feel that "fixing" things tends to fall after "building cool stuff" too often with software in general, since "cool" is relative.

Nicole:

I'm happy to hear that the goal is to get this fixed in the next 10 weeks.

FYI - It might help if there was some forum available where you could list the targeted/prioritized changes that are taking priority over this "for more customers", because what we see on our side are lots of NEW features being announced regularly based on guesses for creating additional revenues rather than changes affecting every-day usage for existing customers like this issue. (It's a common problem in Software unfortunately).

Clearly this problem won't show up for someone before they purchase, only something you run into after using the product for awhile and start to consider metrics.  It's natural that PMs will be driven towards expanding the customer base, but "taking care of customers" is the flag Zendesk likes to hold up, and in this case, these recent comments are simply trying to reflect the frustration that this change needs to be taking as long as it has.

Neil

Nicole:

Editing the fields IMO is far more important than tagging, and I've stated such earlier on this thread. 

I do understand your dilemma in the fundamental change this request make in the system.  IMO if you could add a new state after SOLVED before fully CLOSED that was essentially "CLOSED_EDITS_FROM_ADMIN_ONLY" and allowed tickets to remain in that state for at least 6 months or possibly 1 whole year, that would be a good transition time that probably covers 95% of the needs for those of us asking about this.  My desire, and many others I have read along the way has always been to be able to correct field-entry mistakes that our agents make when marking tickets as resolved.  Since those mistakes today are not correctable, it makes much of the data we try to collect skewed towards ineffectiveness.  So allowing an ability to tweak certain fields during a transition state seems like it would be a good compromise that would be beneficial to admins, yet still allow Zendesk to keep the historical archiving working the same way it does today.

So the reality here is that there are 2 competing needs.  Some need this data to be "frozen" and some are less concerned, or simply do not have such a requirement in their processes.  While I like the idea of "closing" a ticket which locks out the customer from adding comments weeks or months down the road, the fact that this "closure" also locks out agents is essentially the root problem.

So why not keep the rules on ticket "closed" state the same, but add a new "lock" state, and have the "ticket lock" timeframe be a setting that is flexible for everyone?  Those who need things to lock after 1 month would remain satisfied with the current imposed situation, and the rest of us could extend this "ticket lock" timeframe to something longer, like 52-weeks, thus giving us the flexibility we are looking for in making modifications to fields to correct agent errors and yield more accurate metrics.

Well, if you go down that path, the real question would be... why are they having to "lock" this data after only 1 week?  I still don't like the TAG only update idea, I strongly prefer to be able to modify our customized fields, as stated above, since agents make mistakes, and if I can correct some fields our metrics can end up making more sense, that has more value to me than being stuck with an incomplete/incorrect frozen record.  

Very happy to see this now has potential.   It's wrong to assume that our agents are flawless in their field selections, and towards having the system correctly represent the data we want when collating our metrics, this is quite a vital change.  I don't believe anyone wants to remove comments here, just the ability to offer limited users the chance to make updates at intervals that are much longer than the "solved to Closed" time window, which for us is only 10 days.

Although tagging can provide some relief, there are still fields that agents forget to fill in sometimes, and it's frustrating from a data collection standpoint to be unable to modify that data inside the system.  I still think that granting Admin's the right to change custom-field data after a closure should be available so that our data summary reporting can be made more accurate.

+1 - really need ways to make this information more accessible to admins/agents