Features needed for a CRM system

From the mambo forums (dmcole)

• Need much better group handling. I know that this is a priority for Mambo 5, but I can't emphasize enough how the way groups currently work is a major pain in the patootie. And though committees are like groups, committees have internal hierarchy as well, so that I might be the chairman of the membership management search committee and you might be the secretary of that committee and the group might want to contact all committee chairmen.
• If group access weren't No. 1, then the No. 1 request is some type of printing application – for the foreseeable future, we (society) is still going to be tied to paper. While some of our members are computer-literate, we can't predicate the entire membership management system on the theory that all are. That said: the ability to create Avery labels from search queries ("Give me all the members who expired in 2004"), form letters ("Dear delinquent member: Pay up now or you're going to miss all our cool stuff"), renewal forms, post cards. This could leverage much of the existing PDF code in Mambo (I think; or actually, I hope). There should be a methodology to allow some sort of USPS CASS certification (either real-time or batch lookup – which then requires the question of whether you save the standardized address in another set of fields). The basics of one of these jobs should be saveable in the db, to be used at a later time with the current query or with a new query.
• Which begs the question of expiration ... while many non-profits never "expire" donors/contacts, some do. And associations/clubs always expire members. Some organizations run a calendar or fiscal year of membership; others run a calendar year. We need to know (and to be able to query) when a person joined the association/club and when that membership expires. I also want the system to calculate how many years into the future the membership extends. If Member A has a membership that expires on Dec. 31, 2005 and I get a check from her today, I want the system to extend her membership to Dec. 31, 2006 merely by my adding the check number and amount into the correct field.
• Which leads to the fiscal stuff: For one of my groups, they have historically carried three items regarding every membership renewal: the date, the amount and a check number. The check number is carried so that when the member calls up and whines that they paid you $25 on March 30, you can look it up and say, "Well, we recorded check number 1234 at $20." In an ideal world, these fields would be some type of concurrent scrolling – like a spreadsheet. From my limited PHP background, it seems to me that each entry is part of an array in a database field, but what do I know?
• Each member needs a preferred contact method – in non-profits, that is frequently a phone number; in clubs/associations, it's usually a question of USPS or e-mail. Again, need to be able to sort on that field and blast out e-mails or printed letters or a call sheet.
• Which leads to how to handle e-mail blasts – probably need to set up a system similar to those used by listservs (which parse out the domains, sort the records by domain, create one e-mail per domain and bcc all the members who are in that domain). And, if that's going to be there, might as well include other listserv features: message groups, digests, moderation. Members should be able to subscribe/unsubscribe from message groups from their e-mail client or from their membership record. Like a print job, e-mail blasts should be saveable for later use with this query or a new one.
• More fiscal stuff: One of my clients has an annual meeting that costs $10 to attend and also frequently sponsors regional or national conventions, where the registration, T-shirts, coffee cups, bus tours, dinners, lunches and snacks can run into the hundreds – even thousands – of dollars. Each event needs to reside in its own set of tables and not influence any subsequent event. If we're wishing for the moon, a lodging management feature would be great too.
• More import/export: Need to be able to take a dump out of the legacy system (usually Excel, FileMaker or Access) and just squirt it into Mambo – CSV files that would create fields on the fly based on what columns are in the CSV file. Output needs to be able to create CSV files based on queries of multiple fields from various tables, doing joins as necessary.
• Each field carried in the administrative database needs to have a variety of publishing access levels – some fields only appear in the backend, some appear only in the front-end for the member themselves, some appear in the front-end that only members of the same group as the member can see, some are universally available. Some fields can be set by the members themselves to be world, group or admin-only accessible.
• Members for many religious groups (and others as well) are not individuals, but families. Yes, there is a primary contact for the family, but the system needs to understand the concept of the family and that they are related, yet can belong to different groups/committees/etc. Many also want family roles defined.
• Mass updates of a single field – either the entire database or a query-selectable few.
• On-line credit card processing – verification and authorization, handling daily/weekly batch processing, receipt creation, etc.
• My non-profit clients all want fund-raising features – which support prospect management, prospect histories, gift tracking, volunteer management, planned giving/memorial management, matching-gift management and automated task scheduling.