Case Study: Implementing CiviCRM for a religious organization

Background Pogstone's client had already been using a web-based membership database, however that system did not have any features related to households and other features needed when interacting with families and children. They also needed many features related to needs of a typical synagogue that were missing from the previous system. Roll-out process First Pogstone helped them identify and prepare which records from the previous system they wanted to bring into CiviCRM. That was loaded into CSV files, then Pogstone loaded that data into the new CiviCRM database. We did staff training just before as well as just after the data import so the staff of the organization would understand how their data would appear in CiviCRM, and also be able to review the results and work on deduping after the import was complete. Pogstone set up the deduping rules based on many discussions with the client, however the final decision about if any particular 2 records repesented the same person or not was the decision of the organization's staff. Pogstone provided the staff training on how to understand the meaning of the "merge" screens, so they had the knowledge to decide to merge or not with confidence. The next steps were configuring and helping the staff understand how to set up their membership rules, CiviContribute membership pages, and event pages for their major membership signup. Virtually all their members either join for the first time or renew their membership in September, as well as register for a series of major events tied to the fall high holiday schedule; so we were under a very short timeframe to have all these pages and configurations ready. They also switched payment processors to Authorize.net, which took a bit longer than planned because there were a lot of paperwork requirements that were not well explained in advance. First Challenge The event registration pages made heavy use of price sets to allow people to choose various sessions/time-slots available for a given event. However, the CiviCRM event participant reports and related custom searches did not allow the event planner to get a participant roster for each session. What they needed was a printable roster for each session, listing the names of all the registered participants for that one session. What Pogstone created: A new custom search that allows the user to filter on all the options for each price set field, for all pricesets. For example, one priceset had 10 fields each of which had 5 check boxes. So in the filter on the new custom search, this became 50 choices. The user could filter on one or more sessions, and the results showed the participant's name, email, and other basic information about the person. It also included the name of the person who registered them. So in the case that someone registered themselves plus their spouse and children, it was easy to see that all those people were coming together as a group and would expect to be seated together. Second Challenge The client was making heavy use of automated recurring billing via CiviCRM and Authorize.net ARB. The staff of the organization was using the "recurring billing" report on the Authorize.net website, and then attempting to verify that information against information in CiviCRM. This was difficult because the report layouts in CiviCRM do not include the "subscription id" and other data was hard to get to. This made it time-consuming to reconcile the 2 systems. What Pogstone created: A new custom search just for automated recurring billing records. It is laid out in a way that is consistent with the Authorize.net report, and also allows the user to filter based on subscription status and creation date. The staff now spends significantly less time reconciling Authorize.net and CiviCRM. What is still planned as an improvement: List the billing name on the credit card in addition to the CiviCRM contact name, for these often do not match. This seems to occur when a person is registering themselves for a paid event, yet pays with their spouse/partner's credit card. If anyone has any questions about this case study, I can be contacted at sarah@pogstone.com