FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at http://help.fogcreek.com/fogbugz.

Posts by Fog Creek Employees are marked:

Documentation
Release Notes
Network Status

Support Status - filters/API/remote interrogation

Hi there,

We were talking today about our use of FogBugz (on demand) and how some cases were falling through the cracks and not being responded to in a timely fashion.  This stems from a mixture of different approaches to time management and the number of clients that we have.

The best idea that we came up with was that we would like to put together a page with very big text on it showing the number of unassigned inbox cases and those that have received communication from a correspondent after an email was sent to them (from FogBugz of course), and then display that page on a spare monitor in our office so you can simply glance at it (like you would glance at a clock) to see if there's anything that requires attention.

As you might imagine, normally this magic number would be sitting at zero, especially as we leave the office for the day.

I imagine we will use the API for this, polling every 5 or 10 minutes to check for a change in the status (we're using FogBugz on demand by the way).

The first number is easy to pull, but the second seems a bit harder.  I've searched the discussion board for anything similar and not found anything, with the exception of this post: http://support.fogcreek.com/default.asp?fogbugz.4.8323.2

Any suggestions gratefully received.

Cheers,

- Bob -
Bob M Brown Send private email
Monday, March 1, 2010
 
 
Do you keep cases open when they are waiting for customer response?

We always send & close a case unless further followup is necessary from *us*.

So essentially your second number would be open cases in the inbox.
Michael H. Pryor Send private email
Monday, March 1, 2010
 
 
Thanks Michael.  We normally Send & Close when we send the final response to the customer saying that the issue has been resolved but often we have to email the customer back asking for more information.

Although your suggestion would mechanically work in this case it seems wrong to close the case our cases typically have many replies from a client as we finalise the work to be done.  For example we'll create a case called "Implement the Foo" and then email the customer from that case to clarify their requirements etc.

This approach may be appropriate for a helpdesk ticketing system but not as a workflow management solution for a development team.  This can lead to cases that were expected to receive a response from the customer but never did and so therefore were closed.

Any further thoughts?  I would have considered using the "Download Database" functionality in the admin but it takes the site offline while it prepares the database.
Bob M Brown Send private email
Monday, March 1, 2010
 
 
We keep our customer communication separate from our internal work items.  You can keep them related as subcases if you like, but it gets messy when customers are sending in emails and the case is assigned to a developer.  It's better for us to have the support people contacting the customer and relaying info to the devs.

Which means we can close the cases in Inbox if they are responded to...

But either way, if you don't want to do that, then just Resolve them (waiting for information) and then your second number is just "active" cases in the Inbox.  If the customer responds, the case will be reactivated.
Michael H. Pryor Send private email
Tuesday, March 2, 2010
 
 
Thanks Michael - we're on the cusp of being able to separate our developers entirely from our customers but for now we have developers who deal almost exclusively with our clients. Sounds like there's a solution in there somewhere.

Thanks again,

- Bob -
Bob M Brown Send private email
Tuesday, March 2, 2010
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.