Question

Please pardon the long-winded post... workflow stuff is tricky, so I want to be sure to provide enough context.

The short version: How can I put cases into an "up for grabs" pool, but still make them show up in our tech support pool if the customer pings us on the case?

---

We've been using FogBugz to handle e-mail support requests for a while now, and the following workflow has been working very well for us:

1. User e-mails in with question/issue.

2. FogBugz gets the mail and assigns it to a "Tech Support" user as a new case.

3. We have someone on tech support duty who works through the queue, clearing it out by either responding to cases and closing them, or by assigning the case to someone who can.

4. In either event, if the case is closed and the customer replies, the case is re-opened and re-assigned to the "Tech Support" user. That way the message re-enters our normal tech support process and the customer will receive attention quickly.

   NOTE Some people have more success with using the Workflow feature to reassign re-opened cases to the case closer. This results in better continuity of care, and might become the default functioning of FogBugz in future versions.

When we determine that a case is a bug, we assign it to a developer to fix. Currently, the developer is responsible for triaging his own bugs.

However, we're finding that this has problems:

1. Developers & Management prioritize things differently.
2. Every developer has a backlog of bugs that are "assigned" to him and are open, but he may not have time to get to them.

We'd like to create a virtual user to assign these cases to to be triaged all together as we plan for our next sprint.

The problem with this, though, is that if a case is open, and it's assigned to an "up for grabs" virtual user, if the customer e-mails in with updates/questions about a case, the e-mail goes to the "up for grabs" user's e-mail address.

This is better solved by spawning an eng case rather than moving the case from the customer queue into the inbox. We've found at Fog Creek that devs and support reps work on different time scales and one is not compatible with the other. It's far better to separate the inbox case, which is mostly about communicating with the customer, from the dev case, which is about writing and checking in code. That way, you don't have the customer waiting on a dev for communication.

But we don't necessarily want to see e-mail for that user anywhere. I thought about directing that user's e-mail to an e-mail list, but I'm sure we'd quickly get overwhelmed with all of the cases that get assigned there for triage.

But if we get no e-mail for that user, when a customer e-mails in, he will go unanswered until someone happens to look at the case in the "up for grabs" queue... which may be a week or more.

I thought of two solutions to this problem, but neither were workable:

1. If there were some Workflow option to assign a case from the "Up for grabs" user back to the "Tech Support" user when an e-mail was received, I could do that and alleviate my problem.

2. If there were a way to somehow search for "Tech Support Cases AND Up For Grabs Cases that have received an e-mail but not been responded to", I could set that up to in essence extend the Tech Support queue to cover those cases too.

So, finally, the question:

How can I put cases into an "up for grabs" pool, but still make them show up in our (or some implementation of a) tech support pool if the customer pings us on the case?

Thanks. :)

Answer 1

Hi Cody,

if I read between the lines, I get an idea for what you are looking for; and from my perspective at least, your desired future state doesn't necessarily involve virtual users.

It sounds like you would like to maintain the responsiveness of having the tech support people keep their conversation with the users, and at the same time you want to exert more control of the engineering changes that take place.

Ok, so here's an alternative proposal (which I haven't tried, so I can't be sure that it works, but it sounds reasonable to me.)

The e-mail conversations that take place between Tech Support and the customers are never assigned to anyone else. When a Tech Support person comes across an issue that needs engineering support, they apply a tag to the case such as "for_devs".

Every week or so, when the devs are planning their next sprint, a tech support person goes along (or their representative from management), and a query is run on all cases that have the tag "for_devs". These are discussed, and either rejected or accepted.

If the case is accepted, the tag is changed to "devs_accept", and a new case (a bug) is created that references the original conversation using the pound symbol and the case number (so it becomes a link). The new case is also linked from the original conversation, so now there is a two-way link. The devs can put a comment into the original conversation so that the Tech Support person knows what is likely (eg., quick fix, low priority future fix, etc.).

If the case is rejected, the tag is changed to "devs_reject", and then the devs put an explanation into the conversation for the Tech Support person, so that the Tech Support person can give a plausible story back to the customer.

If the dev needs to be able to contact the customer for further information, they can do it by referencing back to the original conversation and getting the customer's details from that.

The devs can do their prioritisation with the Tech Support rep using the project backlog plug-in, or however they want to do it. In all cases however, they are working on bugs and features, and the conversations are staying with the Tech Support people.

The Tech Support person can choose to close the case with the customer as soon as they want to, after the case's tag has changed away from "for_devs". (I expect that they wouldn't do so until the customer has been notified, but each case would be treated on its own merits.)

What do you think?

Peter.