A forum for technical support discussion related to Fogbugz.
When a customer emails in a new feature, it goes to project 'Support', if we like the feature idea then we currently assign that case directly to the relevant project and it lives on from there.
However I see some problems with that and am considering changing to a procedure where customer support issues are not ever directly changed to another project, but new cases are created in the relevant projects if necessary. The aim being to separate customer support cases (and their responses and closing times) from the features they are related to.
Creating a new case seems better, because:
a. Support response/closing stats aren't affected (I do like to see numbers of support cases per month etc, to see if there are trends etc).
b. Internal feature titles are much better than customer feature titles (our customers tend to use single words in the subject, usually the product name).
c. Multiple customers reporting the same issue can then be referenced by the one definitive non-customer-facing case.
d. The customer cases then track the response and feedback of the customer, and the feature case (which has a reference to the support case of course) has reduced clutter and only internal discussion.
e. Does it stop customers getting a glimpse inside the development process? I think they see status changes for the case... so might see a series of resolveds, reactivated, etc.
My fear is that perhaps the admin overhead makes this approach nonviable... I intend to try it, but am wondering if others have tried it already or perhaps have evolved a better approach...?
I have seen the same problem with cases started from a customer and have wondered what the customer sees from their perspective. Especially with the case status changing several times. I like your idea and it makes a lot of since but what is the actual overhead? The support person has to write up a standard case and might have to do some screen shots to explain? Huge pro is the support case can be documented and resolved!
Thanks for the idea...need to think more about this for our company.
Wednesday, December 3, 2008
We do this religiously at Fog Creek. There's two things here. First, we need to decouple the work of the inquiry case (answering the customer, dispensing warm fuzzies) from the work that the inquiry implies or requests (writing better documentation so you get fewer of that type of inquiry). If you don't do this, the customer can wait for a response for days while an engineer ponders how to address the feature request. So the best thing to do is spawn a related case.
This is known internally as "Fix It Twice". http://www.joelonsoftware.com/articles/customerservice.html
But there's a problem with the discipline of Fix It Twice. The part of my brain that composes responses to customers is not the same part that enjoys mapping out clean repro steps or clear use cases... or even figuring out what to do about an inquiry that clearly needs *something* done about it. The queue-based part of my brain wants to do one thing: get through the queue. So, what to do about that feature request that's actually pretty brilliant?
FogBugz is pretty much built around the philosophy that minimizing friction in case entry and removing barriers (both actual and mental) to entering cases results in more cases making it into FogBugz and more cases make FogBugz more valuable. Because of this, and because we allow setting of URL parameters, I can pre-decide pretty much everything I need to about a spawned case and drop that into a bookmarklet (most actual parameters removed, no warranty implied, etc.):
Replace each XX with values appropriate to your install and process.
You can see here that I set the project and area. That corresponds to a special "Fix It Twice" area I created for support. I set the priority to 4 so that if I sort by priority, the default priority of 3 for inquiries puts all open cases in the inbox above the fix-it-twice cases. The body of the case comes in pre-populated with the case it came from.
When I'm looking at your inquiry and I decide that there needs to be a bug or feature or doc, it's exactly two clicks to open that case. I leave them (Untitled) to indicate that they need thinking about, but I could just as easily add an sTitle parameter to the URL. When I catch up on the queue, I dive into the Fix It Twice area, move the case into the FogBugz or Copilot project, give it a real title, set of steps, and priority, and assign it to an engineer.
This approach has several benefits:
- It decouples communication turnaround time from engineering turnaround time. Because customers deserve a reply even if you don't have a good answer for them (yet).
- It minimizes the task-switching penalty of going from communicative thinking to analytical thinking by letting you work through the queue.
- It mines all the value out of the inbox.
For more on parameters in the URL: http://www.fogcreek.com/FogBugz/blog/post/A-Halloween-Treat.aspx
Would love to hear your comments on this process.
My only comment is - this should be a button in FogBugz itself.
Wednesday, December 3, 2008
Thanks for that detailed response Rich, I'm impressed that you have evolved the process and automated it, that sounds great and I will definitely be raising this internally to see if we can adopt something similar.
The bookmarklet approach is cool too and may be the deciding factor if I set that up for our support team.
(Alex I suspect your feature request there will be causing a new case using that mechanism :)).
Btw Rich, do you carry out much analysis of support-case stats, using say CaseDetective or Tableau (which looks great but I have not tried)?
I have made limited use by looking at volumes and rates per customer (divided by number of users) to see whether there are significant discrepancies for targeting followup training etc, and would like to use it for identifying aspects of our software that cause the most support calls... this becomes a project in itself though in terms of getting the 'Area' granularity right (too many and people will use 'Misc', too few is not specific enough) and finding ways to associate cases... but I suspect there is additional hidden value that I could be mining from Fogbugz... :)
Alex: the ability to spawn a case will be included in FogBugz 7, probably in a highly configurable way, but my process is constantly evolving, so it's more important to *me* that FogBugz be interoperable/open to manipulation, than that it provide a best practice. As I've seen over the months here, best practices change with circumstances and can always be improved. Hopefully, the way we're doing 7, you will be able to decide how this should work best for you and implement that yourself.
Mike: No, I don't really focus on metrics. I used to, but it never did anything for me. In my previous life, I was the metrics analyst for the premium support team for a Large Technology Company whose products you probably use every day. There was tons of usable data, but no management impetus to actually improve the process. In my view an ounce of Fix It Twice is worth a pound of metrics.
When I do use metrics, I have two clear rules:
- Metrics don't tell us the answers, but tell us where to ask questions.
- Don't ask for a number unless you have a clear threshold at which your actions/behavior will change, and have a clear action in mind for reaching that threshold.
If I track the volume of tickets and see a dramatic uptick, all it is going to do is make me clench up. The uptick doesn't mean I'm necessarily slammed. It might mean there's an On Demand issue that's going to go straight to the sysadmins and be resolved quickly.
That leads to my third rule of metrics:
- Wherever possible, use downstream metrics.
The piling up of undifferentiated Fix It Twice issues is MUCH more indicative of my being slammed than any spike in incoming traffic. That's a secondary metric that looks downstream in the process for an indication of what's going on upstream. It's a good indicator for other folks here to jump in and help for a bit until I get caught up. Fix It Twice then becomes a record of everything I'm NOT doing that I should be doing. In my prior job, we didn't keep track of what we should've been doing because it didn't matter, because we never had enough staff to even cover the initial incoming traffic.
I could go on for hours, but I'm neglecting the queue.
Angelo: Yup, that puts it pretty succinctly! I think we do a decent job of this for now.
This topic is archived. No further replies will be accepted.Other recent topics