Missing features in CiviCRM ...

Published
2008-06-08 12:12
Written by
With Blackbaud's acquisition of Kintera, there has been some talk of what this means for the nonprofit sector. This along with Convio's acquistion of GetActive last year reduces the options available for the medium-large size NPO's. This is not a bad thing for us, since it makes open source software like Joomla, Drupal and CiviCRM a more attractive option. On that line, I started thinking about some of the big holes in the CiviCRM feature set / ecosystem. Here's my current list:
  • Not having a SaaS (software as a service) that folks can sign up for and get started with Joomla/CiviCRM or Drupal/CiviCRM is definitely our biggest weakness. This raises the bar of who can use CiviCRM and hence is a significant hurdle. On the other hand not having to focus on a SaaS service has allowed us to move much faster and make the changes needed for the platform to scale and become more solid. There is a forum discussion here on CivicSpace and lessons learnt.
  • A better set of reports and reporting functionality. Our dream of getting the reporting functionality accomplished via CiviReport / BIRT does not seem to be gaining much traction. Custom search is starting to play a bit of reporting role and it will help us build some standard reports for the short term. If interested, check out the reporting functionality from Democracy in Action and Raiser's Edge
  • Pledges are an essential component for most organizations
  • Personal Fundraising are quite important for many organizations and are probably going to get even bigger over a period of time. We hope to merge some of the PledgeBank work to jumpstart this feature
  • Better Member Management functionality and integration with other components (discounted rates for members on events, register for an event => become a member etc). The drupal module civimember_roles is a step forward in that direction.
  • Matching gift management. This is a pretty big thing in US companies, and I suspect might be applicable to quite a few european countries too. This enables orgs to effectively double the amount they get (in most cases)
Thats on my list. What do you think is missing in the Drupal/Joomla/CiviCRM ecosystem to be a compelling alternative to Convio/Blackbaud?
Filed under

Comments

Anonymous (not verified)
2008-06-08 - 13:02

Lobo,

A few thoughts...

1) Forgive my ignorance, but what do you mean by ASP?
2) I think one of the missing features is the ability to process CC's without using 3rd party "pingback" mechanisms that require the donor to create accounts in another system. That would simplify recurring payments at a minimum. Grant that takes CiviCRM security requirements up more than a few notches.

3) A sponsorship system is also missing. This would allow things like paid attendance to an event (like a sponsor paying your way into a walkathon), matching gifts, and other fully sponsored events.
4) You really hit the nail on the head with CiviReport/BIRT. Since it requires Tomcat, it's already a bit less useful, but custom search is helping and it's moving in the right direction.

That's all I can think of off the top of my head.

1. and renamed ASP (application service provider) to SaaS, and a link to WikiPedia for further details for folks who are not aware of the term

2. If u use a payment processor like PayPal Website payments Pro / Authorize.net, you can avoid the 3rd party ping back / donor creating an account issue. Note that there are some new security standards coming into play here (http://forum.civicrm.org/index.php/topic,2930.msg12735.html#msg12735). PayPal has recently introduced an API to enable recurring payments. We have not integrated this as yet.

lobo

Anonymous (not verified)
2008-06-08 - 16:45

Cumulative receipts would also be nice. There are plenty of non-profits who send end-of-year receipts for tax purposes. Seems like CiviCRM is only one step away from being able to help there too since it sport per-transaction receipts already.

A big stumbling block that people comment on when I show them CiviCRM as a potential system they could use for various tasks (contact databases, personnel databases, alumni databases, etc.) is that they couldn't use it because they can't control who can view or edit what at a detailed enough level. I know this is the kind of thing that's very difficult to do and still maintain good performance, but Blackbaud's eCRM system, for example, can do this pretty well. They want the ability to allow people to have no access, read-only access, or full access to both certain records and certain fields. Tricky...

Another big one is a full-blown campaign tool. Blackbaud's eCRM has a very nice campaign planning, progress, and reporting tool built in. It lets you create campaigns with goals and timelines, plan actions, contributions, etc. that will get you to your goals, and then as you execute things the actions and contributions that come in allow you to see where you're at relative to your plan. Very slick.

The biggest one of all is the platform Blackbaud has created for eCRM. I haven't coded against personally, but from what I've seen they have a pretty cool system for extending the CRM and adding new features, integrating with other systems, or altering the behavior of existing workflows. They're closed source, so they have to make sure the API they expose is pretty usable and robust. Since we're open source, we can get away with treating the whole codebase as an API to some extent. But there is a lot to be gained by having a clean, well-documented, stable API that people can hook into.

Random other interesting features I've seen or thought of while looking at the competition:

- RSS feeds for interesting reports (volunteers who need attention, new donor alert, etc.)
- Geographical search using Google Maps or some other visual map selection tool to find records based on visual map selections

RE the Geographical searching - this one is persisting at the back of my mind. The issue is that to have the features it would need it requires some mapping software, so that users can add their own layers, eg local government or postal boundaries, statistical area units etc. These would then be able to be used by selecting various polygons on the screen, exporting the coordinates, bringing those in to civiCRM as a custom search, then running the query to find all mappable contacts within the boundaries.
In taking the next step, which is which mapping platform to go for, we need to decide on a solution that works for both joomla and drupal users.

Coming from more of a membership-based organization perspective, rather than charitable-donation perspective --

I see need for improvement with how some of the financial records are managed. For example:

1) Inability to generate invoices (or receipts) directly from the interface, either from an existing contribution record, or in such a way that a corresponding contribution record is created. Many of the orgs I work with still rely on invoicing by snail mail for membership renewals, etc., and it's difficult to effectively track those financial activities in CiviCRM. This is relevant for event registrations too -- we often accept registrations with the corresponding payment pending. The capability for that record keeping exists, but the subsequent invoicing and follow-up can't be done within CiviCRM.

2) Related -- In general, the idea of following up on delinquent/overdue payments is difficult to perform. For example, if I want to know accounts receivable for Workshop A, I have to create a custom search. I can look at all "pending" contribution records, but cannot easily perform the filter by event on that data. The contribution source field "may" be used for this purpose, but because that field is editable, and manually-created contribution records won't contain the same auto-filled data for that field, it is unreliable. It may be possible to run an advance search to retrieve a list of people fitting this criteria, but the data export contains none of the relevant financial/event fields, so it's virtually useless.

One more financial thing I meant to include --
CiviCRM assumes people pay in full when purchasing a membership or event. As those of us in the association world know, that is rarely the case -- either because people can't add, or they change their membership/registration details after the initial purchase. To improve how CiviCRM handles financial records, there needs to be a way whereby I can associate multiple payments with a single membership or event purchase, and also run reports to find out if there is a balance due on a purchase.

On the top of the pre-sales questions, I encounter :

- can we fetch the contacts from within outlook ?
- can we see the emails sent from outlook in civi ?
- can we send to a group from outlook ?

(replace outlook by any other mail client)

For the last one, we have a working solution with the integration with a mailing list manager, kind of hackish but does the trick

X+

Most of the associations I work with maintain discussion lists (listservs) for leadership, committees, and other such groups. It would be great if CiviMail was extended at some point to enable that type of capability. For example, I would love to have a discussion list whose members are defined by a CiviCRM Group. As the group changes (e.g. Membership Committee), the discussion list subscribers automatically change.

The parent comment reminded me of this because it would be cool to have all discussion list emails routed and tracked through CiviCRM activities. I could go in at a later date and confirm that John Doe received Email XYZ as a member of the membership committee.

I realize that discussion lists are a big elephant to eat, but this would be great. We recently bumped into this same issue of committees and discussion lists and ended up deciding to just use membership in the Mailman list as membership in the committee. I'd rather use CiviMember, and then just have that membership automatically include them in a discussion list. Mailman seems to act like an island, but Sympa's website says its designed to be integrated with other apps. Perhaps the solution here is to come up with a bridge between Sympa and CiviMember. We had to take the cheap way out because we are under a lot of accountability right now on how we spend our grant money.

As clay mentions this is too big a project to take on. The best bet would be for someone in the community to step up and contribute Sympa integration (which uses mysql) and seems to have an interface to deal with external lists etc

On the Tomcat-based reporting thing: we are moving to a VPS hosting solution now and I have been told that being able to run Tomcat in addition to the usual LAMP stack required for the main website would require their top plan because of the amount of memory usage. Its just not feasible. Reports are a major thing for us, and I have to tackle it, so I'll share what I come up with. When we migrate to the VPS we'll be upgrading CiviCRM to the latest full release and I'm excited for the custom search stuff.

Mainly I'd like the ability to find both organizations AND individuals with certain relationships to those organizations, based on some search criteria about the organization. I am hoping custom searches will enable this. For example, we might want to find all orgs who have value X in custom field Y, and then send an email to the primary contacts. This comes up over and over.

Also, we recently had an election amongst our membership to elect a Board of Directors. Surely this must be a common thing. I facilitated it using an advanced poll component for Joomla and just modified it a little. I kind of hacked a way for the logged in user to be checked for a certain CiviCRM group membership in order to be allowed to vote. We had a complicated process for each org to identify a person with authority which we called a "certifier", and then the certifier could identify a voting representative. Only the people certified to vote on behalf of their org (added to the voters group in the CRM) were able to vote in the poll. Could this kind of activity be appropriately part of CiviCRM?

On reports --
Ditto on the need to have some alternative options for reporting. I did a lot of research a while back and there's not much out there that's open source and that doesn't require Tomcat. But I was thinking -- what if there was a way to treat the Smarty templates as reporting mechanism. I'm envisioning a new "action" in the search results dropdown for "send to report." I do my search, select that option, and am given a series of "reports" available, that really are just smarty templates. I choose my report and the result data is plugged in. It would be a crude mechanism, as Smarty templates have their limitations, but I think it would help address some reporting needs.

On the polling comment --
I recently did something similar for a client, but accomplished it within CiviCRM (I originally though of using another Joomla extension, but then realized I really didn't need to). It was a professional society that wanted a mechanism to handle proxy votes for the upcoming Board election at the annual mtg. I created custom data fields for the ballot and exposed them through a profile. The nice thing was that it basically ensured one vote per member, as they needed to authenticate before the profile form was available. And all the data is stored with the user, so it's easy to tally votes and confirm the legitimacy of the voters.

But it gave me some ideas for extending custom data and profiling. It would be really cool to be able to add custom fields that have a one to many relationship with the contact. For example, if I choose to replicate this same situation next year, I will need to create new custom fields specific to the year. A few years down the road, this has the potential to really clutter my database, as there is a separate set of data fields for each year. I could disable the sets to clean up my contact form, but maybe I actually want that data available to review. Anyway, the better way to do it would be to have a 1 contact to many custom set records structure -- no different than how membership/contributions/events are tracked and viewed -- except it would be custom fields. It may not even be that difficult to create the interface workflow for this. When creating a new custom data group, one of the settings could be a toggle as to whether this data group is a one-to-one or one-to-many group. The more I think about this, the more I'm convinced it would be a significant addition in functionality and flexibility.

Another cool function idea --
Right now when a profile is exposed to the frontend, you can make it a new form input (if the user tries to complete it a second time they are rejected) or an update form (they can keep coming back to update it). It would be nice to have the option of letting the user choose whether they want to update the form. "...you have already completed this form. Would you like to review your original response and update the data?" In my proxy vote example above, I would have preferred to remind people if they've already completed the form before letting them edit/update it. Because yes, people will come back three times to complete the form because they don't remember having done it. And each time it updates their answers, which may or may not be what they want to do.