SupportFlow / supportflow

A WordPress plugin to manage support tickets
90 stars 14 forks source link

How to know whether a ticket is waiting for a customer or support agent? #242

Open DavidAnderson684 opened 9 years ago

DavidAnderson684 commented 9 years ago

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.

iandunn commented 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.

Statuses

Here's my interpretation of the statuses:

@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.

Workflow and Automation

  1. Customer sends an email
  2. A new ticket is created with the Open status
  3. The agent replies, and the ticket is automatically set to the Closed status
  4. If the customer responds to the agent's reply, the ticket is automatically set to the Open status
  5. The cycle repeats until the issue is resolved. If the agent was the last to reply, the ticket will already have the Closed 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.

DavidAnderson684 commented 9 years ago

This helps clarify things.

My thoughts on the flow:

iandunn commented 9 years ago
DavidAnderson684 commented 9 years ago

I agree with all that. I'd say that a site-wide setting related to auto-closing would be a sufficient beginning.

brandondove commented 9 years ago

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:

DavidAnderson684 commented 9 years ago

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.

brandondove commented 9 years ago

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.

iandunn commented 9 years ago

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.