Hi,
The challenge I’ve had using those two tools together (this may sound obvious) is that one - sfdc - is customer facing, and the other - bugzilla - is good for internal use, but a really tough tool for people other than developers to use. Here’s what I’ve found (and this is consistent across companies/products I’ve been associated with):
The fundamental distinction I have tried to make is that between a *customer* issue (something a customer calls in about) and a *product* issue (an actual defect in the product). These two are not always equal. In the early days of each product (or release), I’ve found that *most* of my customer support issues turn out to be product issues. Companies generally make a number of, er, interesting discoveries about how the product works in the real world, and I’ve tracked most of the issues in *both* sfdc *and* bugzilla - with sfdc managing the *customer* aspect of the issue, and bugzilla being used for the development team to track and resolve the *product* issue. You need to create custom fields in both systems to cross reference bugzilla’s bug id in sfdc as well as sfdc’s case number in bugzilla.
Generally assigning the support person/people as the case owner in sfdc and at least on the cc list for the issue in bugzilla will keep them “in the loop” on internal developments so that they can then manage the issues with customers. The services/support/sales team still only needs visibility into sfdc as long as support reps update sfdc with any *significant* development from product development. SFDC has great reporting & dashboards which allow visibility into customer issues (and as far as I’m concerned, the customer perspective is the important one). I’ve used dashboards showing age and status of customer high severity issues and shared it with the rest of the management team regularly to give them a good indication of where we stood with with respect to our customers. It’s much easier to get executive level reports out of sfdc than it is out of bugzilla.
SFDC also has some features (as long as you’re using their professional edition or higher) called “solutions”, which allow you to publish answers to common issues that you can then share internally or externally - and manage them from within SFDC. SFDC also has some “web to case” and “email to case” capabilities that are a good start for web self service. This will give you a good start with those existing tools. I haven’t used their newest self-service portal, so I can’t speak much for its value. The other good thing about tracking this stuff in sfdc is that if you’re a small company and doing alot of pilots to sell bigger deals, providing your sales team with access to status on customer issues can be very helpful.
As a product matures and stabilizes, I’ve found that most customer issues can be tracked solely in sfdc as the issues will be less frequently a result of product problems, so the challenge with dealing with *both* sfdc and bugzilla for typical customer issues goes away. Again, I’ve used the “solutions” within sfdc for providing customers with a knowledgebase - irrespective of whether it is a true product issue or not.
So… in summary, if you *don’t* end up changing your tools, this was a process that worked well for me on both sfdc and bugzilla - I would just use the CRM aspect of sfdc, and only use bugzilla for true product issues. Just be sure to cross-reference the two. In addition to the reasons I listed above, it’s also nice to *not* have your product development team directly entering information into a system that is potentially visible to customers as you move towards self-service).
Good luck!
Nello
| 
.jpg)
.jpg)