Why we migrated from CCB to PCO

Several people have asked me about why we migrated from Church Community Builder (CCB) to Planning Center Online (PCO), which we completed last fall (Fall 2016). I have documented this in a couple of different places (emails, PCO Slack Channel, verbally), but thought I would post it one place where it won’t age out, and I won’t lose where I put it 🙂

---

Choosing CCB

Around three years ago, I was approached to review various church management systems (Chms) for our then 2 campus church, trying to identify the best solution that would fit our current and planned future needs. This included basic things like a member database, giving/finance management, some level of groups and events management w/attendance, room and resource management, and a communication structure underneath all of that to consolidate communications. I looked at all the solutions I could find or know about, and at the time, the best solution that fit our needs was CCB – they checked off all of the key areas that we needed, and during our eval their support team seemed to provide a really friendly, helpful interface for both understanding their system, as well as resolving issues. Based on all this, I recommended CCB to leadership.

Keep in mind that, during the time that we had evaluated and were using CCB, we had no plans to migrate over services planning/scheduling functionality – I was the worship director at that time, and we used and LOVED PCO (later PCO Services) — it was an awesome tool, addressing all of our needs, so any minor benefit of having this information integrated in CCB was outweighed by the major loss of the smooth, full functionality of PCO for services.

General Issues

Following the decision, we began to work with CCB, set it up all campuses, integrated giving, events, attendance, and groups. Most of this integration was done by the office staff, but they would routinely have questions on how something could be done, and as the technical point of contact, they were directed to me. If I could not figure out the issue quickly — having reviewed their online materials, documentation and other user questions — I would call CCB support to ask what was often a narrowly defined technical question on how to do something. For most questions directed to CCB support, the response was either “we can’t do that” or “we have no plans for that”. Keep in mind that many of the things that I was asking about seemed like natural functionality that their customers would want, so I would expect support to have at least addressed these before, and hopefully, have a ready answer. But many times,  the response seemed somewhat confused like I was asking a physics question.

One example relates to CCB lacking a responsive/mobile interface or mobile app — more than half of the traffic to our website was mobile, which is becoming very typical for churches, so having a mobile-ready interface is really a requirement, not a bonus feature. Responsive design has become so critical in the industry that Google even began to include it as criteria for their search rankings, giving you negative markings if you did not have responsive design. Literally, everyone was moving towards responsive design, yet when I asked them about this on a few occasions, CCB responded: “We have no plans for that”.

Design Issues

Some of my questions to them were more design-related, such as their model for multi-campus  – CCB does support multi-campus, by essentially creating a separate container for each campus. This means that every user, every event, every group had to be associated with one and one campus only, making cross-campus or church-wide events difficult to take attendance for. When our office called CCB support, their answer was to create an event per campus, and take attendance for each, even though it’s only one event! When I raised this as an architectural limitation, I somewhat got an apology, but “no plans to change this”.

And then there were simple design quirkiness issues– using kids check-ins for Sunday morning, each campus has specific service times set up ahead of time in CCB, yet a user trying to do a check-in has to manually select the time of the service or CCB would complain that “no service at that time”. Put more simply, CCB has already been configured with the campus service times, yet still asks you to manually input it, and complains if you didn’t get it right. It seemed like a great opportunity for a pre-populated drop-down list with the service times, but again CCB said: “We have no plans for this”.

Escalation

Over time, my frustration level was increasing with CCB, and I began escalating these issues to our leadership, recommending they escalate to CCB. Out of this, the CCB leadership (including their CEO) had a conference call with our senior team, and promised that “everything would be addressed”, “all questions would be answered”. In context, I have managed support organizations for software companies, as well as having been an IT director, so I have been on both sides of the vendor <-> customer relationship. So, I cautioned the senior pastor that CCB may promise the sun and the moon, but the patterns that caused these kinds of issues were usually cultural to the company, and usually did not change that quickly — only positive results and deliverables will prove how serious CCB is in fixing the issues.

As an outcome of that call, I was scheduled to have a conference call with one of their “key experts” to resolve my problems. This call was also a bust – the person they assigned to talk to me was a trainer because the assumption was that “all of our problems were due to just a lack of understanding of their system“. So as soon as I started raising all of the key issues, she had no answers, said she had never heard of these issues, and promised that she would get engineering to respond directly back to me – still waiting for those responses.

Looking at Alternatives

In parallel with this escalation with CCB, I had been steadily watching the Planning Center Team add functionality and apps to their portfolio, and had been slowly promoting the idea of PCO’s potential to the pastors. While there were far more available features within CCB, PCO would soon/eventually have all the functions that we actually use. With the announcement of PCO Groups in Summer 2016, the checklist required functionality our now 3 going to 4 campuses would require. Based on this, I made a more formal proposal to the senior pastor to conduct a feasibility study, doing an initial trial on each of the PCO Apps and comparing it to what we needed. As I had hoped for, the feasibility study was very successful, with the PCO Suite addressing all of the key areas that we needed.

Security Questions

Based on the feasibility study, and the increasing likelihood that we would move to PCO across all apps,  I begin to dig more deeply into the documentation, and also began watching most of the Planning Center University videos online from a recent event. In that video, Jeremy, the Groups and Giving product manager, discussed user access for Giving being password-less, including some of their background reasons. Having spent a number of years managing Security or Security consulting, I’m pretty familiar with the weaknesses of passwords and have implemented various two factor systems going back to the 90s to address password weaknesses. However, the methodology that was being used by Giving was to send a time-limited URL to the user’s email, which has other risks  — email has become the initial target of choice for many hackers.

With this concern in mind, I sat down to write a short question on this the Giving support team on a Saturday afternoon, expecting that I would get an answer back (maybe) early the following week. Early that evening, I got a full-page long response from Jeremy, the product manager, addressing my specific question in detail. His response was so thoughtful and specific, I needed to take a day to craft my counter-response. So sometime on Monday, I sent back a page-long response to Jeremy, somewhat challenging some of the premises, somewhat asking about the timeline to get to true 2factor authentication. Later that day, Jeremy responded again with a more than one-page response, closing with something to the effect of “I’m sure we could continue to debate this, but we both made good points, and the bottom line is we both agree that passwords are fundamentally flawed, but we just disagree on the steps to address it”.

The Push for PCO

Based on this, I began to push even more vigorously for full migration to PCO — even if PCO did not (yet) have all of the features, I would rather work with the company that fully engages and listens to their customers and is constantly thinking about and pushing the boundaries on how their solution can address church operational needs. Even if they don’t have Feature X yet, I already know they are thinking about it, or are open to our suggestions about it. This makes them a much more dynamic (and fun) company to work with.

I will document some of our migration experiences and tips in other posts, but we completed the migration in the Fall of 2016 and have continued to be impressed with their thought leadership in Chms and their responsiveness.

---

** For the skeptics out there (I am one of you) — neither I nor any organization I am related to is or has been paid/sponsored/subsidized by Planning Center Online/Ministry Centered Technologies in any way — this is just our experiences documented to assist other organizations in their decision making. Also, keep in mind that our requirements may be different than your requirements, so it’s always critical to start with requirements definition (i.e. what features/functions needed vs wanted, and how they are used) to guide decisions about what solution will work for you.