This case study was originally posted on the CiviCRM Forums.
Kehilat Hadar is an independent prayer community on Manhattan's Upper West Side in New York City. The organization has an annual budget of over $170,000, an email list subscription of over 3,000 and is almost entirely volunteer run.
CiviCRM has played a key role in enabling the transformation of operations at Kehilat Hadar over the past few years.
A transformed solution would contain the following key components:
At Kehilat Hadar, we sought a solution that had the following characteristics:
Kehilat Hadar has found much success in using CiviCRM. This is true at a broad level: it has facilitated event registration and campaign execution. But we have also really enjoyed some of the more fine grained features, such as being able to geographically map users returned by a query and integration with Drupal Views for displaying data.
Kehilat Hadar has (proudly) run the implementation of CiviCRM in house, without an external paid consultant, relying on volunteer support from within the community. From an IT administration point of view, we benefit from having a unified system that handles the majority of our organization's needs. We have tried to reduce code-based customization as much as possible, both to reduce volunteer work effort and to facilitate as-smooth-as-possible upgrades when new releases are issued.
CiviCRM has served Kehilat Hadar well in providing its community members with an improved and consistent user experience. CiviCRM's capability of integrating with Drupal accounts is a huge plus, allowing for single user accounts per actual user on our system, and allowing users to maintain their own personal data. We very much wanted to avoid having duplicated lists users for fundraising, for general mass emailing and for programs, and CiviCRM has allowed us to accomplish this.
In 2012, we're looking at expanding our capabilities for allowing users to update the information for their family members. This would assist our administrative processes in targeting community members during campaigns and in understanding the demographics of our extended community - participants, former community members, leadership, and donors.
Overall, using CiviCRM, Kehilat Hadar's organizers benefit from a better view of the community, including a span of several years' worth of data. They are using this data to run targeted fundraising campaigns and track interests in specific initiatives or programs. What's so different from our previous model is that the platform enables the tech-savvy lay leadership of the organization - that is, not programmers - to run and drive events, campaigns and so forth, with only limited technical guidance from Kehilat Hadar's technical team.
We've found Drupal Views integration helpful for segmenting access to CiviCRM Data. For example, for some events, we share tabular participant data with an event team, but members of that team do not need access to any financial data. In such a case, we'll give those users access to the Drupal Views, and restrict CiviCRM access to users with broader data needs. We do also have certain roles in the community where restricted levels of CiviCRM access is granted.
On the financial side, integrating CiviCRM with a merchant account, rather than using a redirect to Paypal, has resulted in substantially increased rate of completed transactions, with over 20% more transactions in a recent campaign over the year prior, as we have fewer users abandoning their transactions after getting punched out of Paypal. Going forward, we're looking at integrating CiviCRM more tightly with our accounting systems. We'd love to see ways to more easily remind users of unpaid events and donations that include the amount expected available as a token donation.
For the most part, transitioning to using CiviCRM has been smooth. Challenges have included working through and around some of the bugs found in various releases. Any serious issues we have encountered have been addressed in follow on releases. We've brought some issues to the attention of the Civi Community and have benefited greatly from the community forums.
From a technical point of view, there are some aspects of CiviCRM which were not so simple to set up. For example, configuring outbound mail and bounce mail processing had some nuances and documentation inconsistencies. But once it’s up and running, it works really well.
In terms of the profiles functionality, we would love to see the ability to present fields on a conditional basis as well as the ability to set field validation through the configuration interface. We would also like to be able to easily tie profile field selections to pricing options and currently this requires coding.
One of our biggest pain points is that after an event registration is submitted, payment selections cannot be changed for that participant. For example, imagine that someone emails our event team to opt in for a housing upgrade after their have registered initially. The tooling currently won’t allow for a change to the price selection. This is something we have worked around by tying profile selections to pricing options programatically. Then, after a registration takes place, if a change is required, we can change a user’s profile selection through Civi’s participant management tools, and manually track any pricing changes that need to be resolved outside of CiviCRM.
All in all, we’ve been thrilled with Civi. The leadership at Kehilat Hadar has been enthusiastically sharing our experiences. Several other peer and related organizations are considering it for their needs, and at least one other organization has adopted CiviCRM as a direct result of our experience. We're looking forward to continued, successful use of CiviCRM and upcoming developments in the platform.