James Hastings

Andrea Saez

Customising your statuses is important when you want to seperate your tickets in a more precise way. For example, I have two statuses for our Dev process. One is to reflect the fact that an issue is in an active Sprint, another one to reflect that, while identified as a legit issue/improvement, is unlikely to go into development anytime soon. This allows for easy access to said groups of issues. And I can fit them all on the one page.

There is also a efficiency issue with not being able to customise statuses. You can create a custom field to allow a user to move between a broader view queuing system. But this requires the agent to now take two actions when submitting a response to a ticket.

1. Change the queue by moving cursor and changing the custom field on the left side of the screen.

2. Now submit the ticket with the button at the bottom right, changing the status field as required.

As opposed to....

1. Submit ticket, changing the status to park between different views.

Doesn't seem like much of an extra time burden when you think about it once. But adds up to lot when you start talking about hundreds and thousands of responses. Its like the customisation makes changing the status redundant, but the action still has to be performed.

Then there is the consideration of the simple fact of human nature - make a process harder and it is less likely to be followed.

These reasons are why Zendesk should reconsider its policy of forcing the status field to be non-customisable.