Scenario:
To get started, I have an organization that needs some very basic CRM added to its Drupal (6) site. The org has been using a Facebook group as its CRM, which works for maintaining a simple membership roster, group emailing, posting notices, and handling invitations/RSVPs for events. Events data is synched from Facebook to Drupal, via a bookmarklet I wrote. The org's membership is between 150 and 200 and administration is all volunteer.
Now the org needs to track the following additional CRM data: extra member/contact information ("extra" meaning anything other than name -- starting with email, phone, and address); event attendance; volunteer hours (needed, offered, committed, fulfilled); interest groups (committees and targeted mailing lists); and donations. Because these are such common and modest CRM requirements, and because a real-world organization needs it, it seem like a good opportunity for a first Drupal CRM prototype.
Questions:
1) Should contacts be nodes? I say yes.
2) If so, how closely should contact nodes be bound to Drupal user objects? One option is a one-to-one left join of users to contacts, such that each contact may (or may not) have one associated Drupal user account. This is straightforward, and will work for the org under discussion, but would not accommodate scenarios where a contact is not a person, such as where a contact can be another organization which can have an arbitrary number of associated persons.
My instinct, in the spirit of keeping it simple, is to define generic contact nodes with an "is_person" or "type" attribute and to leave a single optional field for Drupal user uid. Relationships between contacts and each other can be handled via the same object or table(s) that will describe relationships between contacts and the owner org.
3) How much or how little should CCK be used (given that basic CCK fields functionality moves to core in Drupal 7)? I think this becomes especially important when we consider integration of these pure-Drupal CRM objects with external databases, whether Facebook (as in the example org) or CiviCRM or Salesforce. How much abstraction should the crm_contact.module provide between CCK and CRM functionality?
4) Likewise, how much should CRM Events functionality depend on CCK Date or other contrib modules such as Signup? And if the answer to this should be left open, then how much abstraction would a crm_event.module need to provide between CRM functionality and data-handling modules?
Much more to say, but this is a start. Please jump in now with all of the horses I have forgotten to put before the cart. :)