Case Study: CiviCRM at Kehilat Hadar

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.

• In 2008, the organization's IT systems consisted of a range of disparate components which did not communicate well with one another. For example, the web content was managed through manually edited and uploaded HTML code. A standalone open source application was used for dispatching community mail messages. Applications to accept donations or event registrations were programmed in PHP without use of a framework and required IT support work and customization for each new campaign or event.  Testing was ad hoc and the applications used to register participants for events were prone to error.
• While the solution served its purpose and was reflective of the open source realities at the time when it was built, there was a need to migrate the tools to a more robust solution that included reusable components that could be managed, wherever possible, by tech-savvy lay people who are not programmers. 

A transformed solution would contain the following key components:

• a content management tool
• an event management tool
• a donation management tool
• a master data repository of community member records that store attributes and preferences and that are linked to donations and event registrations
• a mass email communication tool

At Kehilat Hadar,  we sought a solution that had the following characteristics:

• components that would evolve around a common platform
• availability as open source, to reduce costs, to benefit from the community of others leveraging the same tools (and to hopefully contribute back to that community)
• web based, as the organization has no central office
• best practices that can be leveraged by other similar organizations

Process:

• get a team of about 4 volunteers together to run the project
• determination of required components (CMS, CRM, mailing solution, e-commerce and e-donation solutions)
• evaluation and selection of components.  Ultimately, the solution centered around use of Drupal as a content management system. CiviCRM would be used as the community profile tool, complete with a mass-mailing solution, e-commerce & e-donations.
• develop a timeline that enabled the development of the new site, migration of the existing site, deployment of sequential features with sufficient time for them to be validated, tested and backed out if necessary prior to key milestones on the organization's calendar.

Actual Timeline:

• June/July 2008 -  Development of requirements and selection of key components
• September 2008 - Design of component interactions
• September 2008 to February 2009 - Development of the new site
• February 2009 - Launch of the site
• December 2009 - Launch of CiviCRM with limited capabilities for event management for both free and paid events (with PayPal).
• February 2010 - Launch of user-administerable profiles and use of CiviEvent for major event (a conference with more than 275 participants)
• August 2010 - Launch of donation collection through CiviCRM
• August 2011-  Setup of merchant account and integration with CiviCRM to enable direct credit card payment

Results:
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.