A forum for technical support discussion related to Fogbugz.
We use FogBugz mostly for our email support desk. Incoming emails are converted to new cases and assigned to a virtual user "Tech Support Queue". One person is assigned each day to reply to email that appears in the tech support queue.
If the case is completely resolved by that reply then we mark it "Resolved: responded" and that's the end of it. However if the case is a longer-term thing (feature request or bug) then we reply to the customer "we're working on it..." and then assign the case to a real user and leave it in state "Open".
So each of our developers have various "Open" cases assigned directly to them, which they prioritize and work on as appropriate. Now, here's our problem:
Last week one of our developers went on vacation. While he was on vacation, a customer emailed a follow-up to an "Open" case that was assigned to that developer. FogBugz notified the developer via email that his case was updated, but of course he didn't read that because he was on vacation! The customer sent several follow-up emails, getting more and more irritated that we weren't responding. Finally they called us on the phone and we realized what was going on.
How do we handle this case? What we would like is when a developer is on vacation, any emails sent to their open cases should be assigned to our "Tech Support Queue" virtual user. I see that there are vacation options, but they don't appear to have the effect we want.
How can we do this? Is there a way to setup/use FogBugz to do what we need?
Tuesday, February 10, 2009
That does sound like trouble. I can think of a few workarounds right now, and also that maybe things will be better soon.
First, a slight change to your workflow may solve the problem. When you get customer communication, always use that case for just for communication and create a new case to track it internally. Then always close the communication case so it gets reopened and assigned back to the virtual user. The engineer can subscribe to the case if they want to follow along. There are some other benefits of this approach like separating "action today" from "action later" into two cases.
Or, you may be able to configure mail rules that forward all FB mail to a shared (or manager) inbox during the vacation. Not too elegant, but I figured I'd throw it out there.
Finally, in FogBugz 7 there may be the possibility to subscribe a virtual user. I refer you to this posting.
Assigning inquiries to developers was common practice when I started at Fog Creek, and was responsible for 80% of our customer service failures. As soon as I figured out a low-friction way to branch off cases, we've ceased the practice of assigning inquiries to developers. The benefit has been instantaneous and substantial. Our advice is always going to be that the inquiry case has communication work associated with it. If there is other work to be done, spawn a related case in the appropriate project, assigned to the appropriate developer.
Devs work on a different schedule of responsiveness than support folks. This is good. I want someone like Ted to be able to shut the door on his office, block out all distractions, load FogBugz into his head, and bash away at new features without worrying that there's a customer waiting for his reply.
Is it possible to make these bookmarklets part of the FogBugz UI?
Wednesday, February 11, 2009
... and it makes think that there should be a well defined borderline between customer Inquiries and Internal cases.
Practically speaking, one should not be able to change/move an Inquiry from the Inbox queue to an internal Feature/Bug but instead there should be a -somehow automated- mechanism to create one or more cases related (two way links) to the initial Inquiry containing the whole communication.
In my experience, users have no clear view if the business problem they face is a Bug or a Feature or whatever. An email may contain a bunch of things, related or not, including 'thanks', 'smilies', etc.
It is the job of an IT folk to decide (classify the issue).
I have seen this separation implemented in Axosoft's OnTime product and I really liked the idea of keeping things separate.
A warning would be fine I guess ... but how about an additional question asking: "Would you like to create a New case Linked to this case ?"
Maybe something similar to the functionality when Resolving a duplicate case; leaving the original case to Inbox and creating a New case to another Project.
We also create cases for our Development team that are separate from the original customer communication. That way, if the customer replies, there is no delay in getting the case into the hands of a person who should respond. (I also want our Developers to be able to spend time working on code, not dealing with customer replies.)
The vacation problem exists with the Support team as well. Sometimes, a customer communication case may be sitting in a user's queue for a while. (Maybe they're waiting on a fix from the Dev team or need to follow on a case if there is no reply from the customer.)
If someone goes on vacation with cases like that in their queue, here's what we do:
1. Select all your cases and choose RESOLVE
2. Set the 'Status' to "Resolved(Waiting for Info)"
3. Choose RESOLVE.
4. Cases are assigned to "New Support" as that's the 'user' who opened the case in the first place. (Or where FogBugz assigns new cases received via email.)
5. Select all those cases, and assign them back to yourself.
The cases are in your queue, but if a customer replies, the case will be "reactivated" and assigned back to "New Support". That way, someone else on the team can respond while the real owner of the case is on vacation.
Of course, when the person comes back, they need to reactivate the cases to get them out of resolved status. But it's just a few minutes that save having to assign your cases to someone else on the team or risk the customer replying while you're on vacation and not getting an expedient response.
This topic is archived. No further replies will be accepted.Other recent topics