At work we used to have a system where, if a customer reported a problem, the support team would enter a ticket in the product support queue. After triage and evaluation by the team, if it was determined there was either a real defect in the product, or the customer was requesting a feature, then we'd create a task in the work queue for the relevant component, and link the ticket and task to each other.
Various people in the company complained that it was too hard to tell when a fix was done and released, because of the two-step tracking. So we switched to a system where there's only a single queue, and customer problem reports that turn into real bugs or feature requests just get tagged and typed according to their nature. As they are worked, completed, and released, their status is updated.
Today we had a question about one of those tickets that went into production earlier this week, inquiring when it would be complete. Apparently even looking at the status of the exact ticket filed is too difficult for some.
If the new system really streamlined our improved the tracking, it'd be one thing, but from the perspective of the development team, it just introduced a whole bunch of new ticket types and status and workflow changes. Even the support people no longer no how to properly create a ticket when it's something the development team needs to look at.
But hey, at least some people don't have to click TWICE to find out if their pet problem has been fixed yet.