Question

We are using a local installation of FogBugz for years now for developers.

We are considering using FB for Help Desk / Customer support, too.

• The classic "Fogbugz for Help Desk" article seems to be down right now. Any other experience reports on what works well, what not? Is there an updated one that takes into account latest FB developments?

• The FB database is cluttered with information that's would distracting for help desk, especially searches would return lots of unrelated results. So I think of setting it up as a separate database. Any pro's / con's?

• In that case, would we need two licences for someone who needs to access both databases?

Answer 1

We use one installation for development and customer service / sales here at Fog Creek. I find that this is better than separate installations because you can relate customer inquiries with associated feature / bug cases.

For example

1. A customer writes in with an issue: whizbang installation doesn't work with SQL Server authentication.
2. This is a known issue, so the support person makes it a subcase of a "known issue" case in the Sales & Support project.
3. The known issue case is related to the bug case in the whizbang project.
4. When the whizbang bug case is resolved, the support person can get back to all the customers with cases under the known issue case to update them.

Another example

1. A customer writes in with a hairy support issue. the whoosit is crashing in a way the support person hasn't seen before.
2. After debugging in the Inbox case with the customer, it needs escalation to a developer
3. Since development is in the same FogBugz installation, the Inbox case can be assigned directly to the developer.
4. When the customer is up and running, the support person or the developer can create a bug case in the whoosit project and relate it to the customer's Inbox case (which contains juicy repro details)

Answer 2

We had a similar situation and went with the approach of having a separate installation for the help desk and the developers. However, mainly because the help desk is not just a customer support group, but also does our internal network and general IT support. Also, we made this decision while we were still using FB4, so the dynamics may have changed. If it wasn't such a hassle to merge systems, I think I'd seriously consider merging them back.

Ticket History:
If there is a lot of potential for tickets to move between support and the developers, you are probably better off with a single system. If necessary you could do some clutter hiding for the support folks by giving them a separate project code (even if it is the same app) for their tickets and removing their access to the developer project codes. Also, if they can be trained on the use of filters and search axis it should mitigate some of those concerns.

Upgrades/Downtime:
Since we can upgrade the sites independently, we can patch the developer instance more frequently with updates. If we had to take down our help-desk system there would be a lot more red-tape and we would probably only do major upgrades.

Ticket Numbers:
If you go with the multiple database approach, be sure to configure the case number prefix differently for each installation. Otherwise you will run into trouble/confusion when someone references a case number from one system when documenting a case in the other.

Licensing:
As it was explained to us by FC, not sure if it has changed, but I'm sure they will jump in if my information is out of date. You just need to pay for a license for every individual user of the system regardless of how many installations you have of FB or how many they have access to. So if you have 10 people accessing some combination of 3 FogBugz installations, as long as you have 10 user licenses you are good.

One con to the multi-database approach is that managing your licenses can get a little complicated because the built in licensing mechanism really wasn't designed to manage users/licenses across installations, so you will have do stay on top of this somewhat manually.

Answer 3

We are strongly in support of using the same database for support as you use for development. We are in the process of putting together some robust documentation to introduce people to the finer points of using FogBugz for customer support.

You can find the support page here. As of this writing, it's nothing more than a placeholder, but expect it to grow very soon. The current target is to have this in place for our world tour.

Answer 4

We were in a similar situation (we started with FogBugz v3) where we used FB for development and another package for support. A few years ago we moved support to using FogBugz too (same system, same database) and have had no regrets. We're able to use search axis and filters to keep search results relevant.

Answer 5

We use FogBugz for development and HelpSpot for support. We've found that FB is missing some features that are important for running a helpdesk, including:

• The ability to query a CRM database to look up customers
• The ability to show history for customers quickly and easily
• Workflow features for the automatic assignment of cases and automatic reminders (the workflow plugin is 1000 miles from this right now)

This works pretty well for us - where the helpdesk need to report a bug or feature then send an e-mail from the helpdesk system to FB. This way the info is captured at both ends along with links that allow you to move easily between the two.