There may be one single "customer" (the "user base"), which is the typical situation for a traditional bug tracking system in software development -- or there may be many potential customers with many different issues, which is what is generally referred to as a customer relationship management (or CRM) system these days. (A CRM must also store general information about individual customers as well -- but one of the things we know about each customer is the issues that customer has had, and their resolutions.)
So a customer relationship management system effectively consists of a single list of issues, each of which serves as an anchoring point for tasks, and then also permits an optional list of customers. There are additional bells and whistles which may be attached to this system (such as notification schemes whereby customers are automatically informed when issues are resolved, or deadline schemes whereby the priority of an issue or task is at least partially determined by its age and management is notified when a trigger date is exceeded) but all these are extraneous to the basic work of issue tracking. And many issue tracking systems also give users the option of assigning issues to one or more systems or departments. Since this relationship is essentially identical to that of issue-to-customer, I don't see it as extending the model any further.
I'm going to chronicle that effort here; this isn't meant to be a full-featured CRM yet, just a simple bug tracker. But at some point I'd like to explore integrating it with CVS (which is what I use to maintain the code versioning between test and production systems there), for instance.
Once that system is up and running to my satisfaction, then I'll set up a bug tracker for the wftk as a whole. Since the wftk has a more interesting subsystem structure, and since I intend to allow issues to be maintained using CVS for wftk, I think that system is going to be a lot more interesting in many ways. But it still doesn't address the multiple-customer nature of a true CRM system.
So after the bug tracker for wftk is up and running, I'm going to move over to my spam
filtration service and set up a bona fide customer relationship management system for spam reporting
there. Once that's reasonably stable, I can think about ways to build cookbooks for wftk systems of
this type, so that setting up a new CRM can be really simple.