Open DavidAnderson684 opened 9 years ago
There isn't a good way to know yet; that hasn't gotten any attention, so thanks for bringing it up. Right now the agent has to manually manage the status.
I think we need to decide what the workflow should look like, and then implement some automated triggers that change the status based on actions that the agent and customer perform.
But first, it'd be helpful to nail down exactly what the statuses mean.
Here's my interpretation of the statuses:
New
- The ticket has been opened, but hasn't gotten any replies yet. Open
- The ticket has a new response from the customer that the agent hasn't responded to yetPending
- The agent is waiting on something out of their control before they can close the ticket, like waiting for a developer to fix a bug before letting the customer know it's been fixed.Closed
- The issue is resolved, or the agent is waiting for the customer to respond. @VarunAgw, is that consistent with your interpretation?
New
seems redundant; I don't really see what distinguishes it from Open
. Maybe it should be removed?
The Closed
status is used for when the agent is waiting on a reply from a customer, because customers frequently fail to let the agent know that the issue is resolved, so we just assume that the agent's reply resolved the issue, and then re-open the ticket if the customer responds.
Once we create authoritative definitions, we should document them.
Open
statusClosed
statusOpen
statusClosed
status. If they customer is the last to reply, the agent will manually assign the Closed
status.If the agent marks the ticket as Pending
, then it'd ignore the automated triggers and remain Pending
until the agent manually sets it to something else, regardless of replies from either party. Once it's set back to another status, though, then the automated triggers would apply again.
cc @VarunAgw, @Viper007Bond, @brandondove, and @aaroncampbell for their thoughts.
This helps clarify things.
My thoughts on the flow:
Auto-closing:
I think there are different philosophies and preferences regarding whether tickets should be automatically closed when an agent replies. Some organizations want to make sure they follow up on every ticket until it's resolved, while others feel comfortable assuming that the issue is resolved if the user never replies. So, maybe this is a good case for an option. Not sure if it'd be better to be site-wide or for individual users though.Pending Other:
I can see the value in a status where the agent is waiting on a developer or someone else in the organization to do something before they can close the ticket. In high-volume queues those kinds of tickets can add up over time, often because they're for low-priority requests or bugs. The agent's queue shouldn't be cluttered with things they can't do anything about, they should be able to focus on tickets that they can actually address today, so it's nice to have those tickets on a separate screen.Status names:
I agree that the statuses should be more clearly and intuitively named. One we nail down what the statuses will be, we should make sure the names are descriptive enough.I agree with all that. I'd say that a site-wide setting related to auto-closing would be a sufficient beginning.
I think auto-closing a ticket is problematic for the reasons @DavidAnderson684 mentioned above, but providing an option might be the best course. If so, it feels like it would be site-wide rather than user-based though.
My opinions on each status:
New - I think having the initial ticket come in as "new" has value since it gives a support representative an indication that a ticket is available for taking.
Isn't this covered already by a "Pending Support" status combined with no assignment? Having a redundant status for it as well would risk introducing ambiguity. For example, a ticket could be both "New" regarding status, but assigned to someone. What would that mean?
Maybe workflow style names would be better for the final status (i.e. resolved, wontfix, invalid, etc).
I think this is already covered by tags. Resolved/wontfix/invalid belong to the world of software bug trackers - which would be a valid use case for SupportFlow, but I'd suggest it's better to leave the user to make up their own tags for their own use case, rather than pre-specifying some.
I guess I was thinking that "New" tickets wouldn't have an assignment yet. If they're already assigned to an agent, my thought is that they would be "Open."
Agreed on using use case specific tags defined by the users for giving more context.
New - I think having the initial ticket come in as "new" has value since it gives a support representative an indication that a ticket is available for taking.
I think David makes a good point about that being redundant; I'm wondering if a dashboard widget that only shows unassigned tickets would be a better solution?
Open & Pending - "Open" and "Pending" feel like they're saying the same thing to me. Behaviorally they're different though. Open tells the agent they have work to do, while Pending puts the responsibility on someone else. It seems like assigning the ticket to someone else and keeping the open status might be more appropriate behaviorally.
The other person might not be in SupportFlow, though, especially if they're a developer/manager/external company/etc. I wouldn't like having it Open
because that would clutter the Open Tickets view with things that can't be acted on right now.
Hi,
I've been doing some more exploration of this plugin, and there's something I can't work out. How, when logged in to the WP dashboard and looking at the list of tickets, can a support agent discern which tickets are awaiting his response, and which are awaiting the customer's response?
The ticket status gives some help in this - the "New" status can be used for tickets that the agent has never replied to. "Closed" indicates no more replies are expected. The other two statuses (besides trash) are "Open" and "Pending". However, when the customer replies, the status does not change from one to the other (even if it were clear to me what the distinction is - i.e. pending what ?).
235 and #241 are related issues about the status handling. But it looks to me like even without those issues, there's a question about how the post status is meant to indicate which tickets the support agent needs to look at - and which he is simply waiting upon. Apologies if I missed something obvious - I've been sat looking at the plugin in depth for a few hours with a colleague and we've both come up empty on this.