As a multi-campus church, when we decided to migrate to the full PCO suite, we had to work through some considerations to support and simplify our multiple campuses. I thought it might be handy to put down some of the considerations in tips that we used, hopefully, helpful for other churches in similar situations. Of course, it’s got to be stated that not all multicampus churches are structured, operate, or grow in the same way, so what works well for us, may not work for you. Your mileage may vary! Love to hear your feedback or other tips in the comments below!
One of the key things to consider around managing multicampus *anything* is supporting commonality, consistency, and shareability between the campuses, while still maintaining the desired degree of uniqueness in local campus culture, identity, etc. Sharing of resources is one of the key benefits of the Multi-campus model, so designing things to optimize the ability the share and utilize is important.
The easiest way to look at this is likely application by application, So let’s start with –
Services
When setting up the services, the first simple thing to do for us was to create campus level folders, under which each of the campus level services would reside. Pretty simple and obvious, and allows for some basic organization.
One thing we found out (somewhat) the hard way was in the terminology/titles we used for roles across the campuses. For example, if one campus has separate teams for Band and Vocals, but another lumps them together under Worship team, this can cause some confusion. We had teams at one campus called stage for stage setup separate from the tech team, but at another, we had “environment” which includes all of the above. Making these teams (and their underlying organization on PCO) consistent helps the teams to understand the structure better, particularly if team members are shared across campuses, which many small multicampus plants do.
This consistently really helps when applied to team names in Services. We originally had created “Worship Team” and “Service Elements” teams (this latter one are the assignments for opening prayer, announcements, etc) for each campus, which made sense — somewhat consistent. However, when assigning someone to a team, and you use the search function, if all your per campus teams are named the same, you get to pick between “Worship Team”, “Worship Team”, “Worship Team” and “Worship Team”. A handy tip for us was to use a campus prefix for each of these teams — we ended up using a 2 letter campus abbreviation, so these teams became “AA Worship Team”, “BB Worship Team”, “CC Worship Team” and “DD Worship Team”. This way, finding the right team becomes quicker and more accurate when doing these assignments.
Permissions is another area to think through when rolling out PCO, let alone across multiple campuses. It often seems “easier” to just give most people broad permissions, allowing them to see and modify across the platform. But when you mix in the level of training and understanding they have, possible confusion about campus context (i.e. People that go to Campus B think of Campus B as “the Church”, and often dont consider the campuses), strange things can start to occur. We have had a musician modify the service order, thinking he was just modifying “his view” — “as a musician, I don’t need the Opening prayer, the Sermon or notes, etc” — caused quite a panic that Sunday morning when everything in the service order but the music was gone. We have had people from Campus 1 accidentally modify songs (on a Saturday night!) in the service order for Campus 2 — a few times. You could pursue training for all your folks to prevent some of this, etc, but you will also always have new volunteers in the mix. Our approach was to define a simple permissions schema that is used per campus, with almost all rights above view being campus specific. Example — Worship Leader in Campus 1 has full edits for his campus, but view only for the other campuses, allowing him to still get ideas from the other campuses, but preventing accidental changes in these other campuses.
CheckIns
Again, consistency is the focal point in structure and naming. For us, we created separate events for each Campus Sunday Morning, with Locations defined for each Room, and times for each service. Here, we used the same campus prefix for each Location, to make it clear which “Auditorium” a person was being checked into. Most views include the Event as well, so it should be pretty clear.
Broader than just multi-campus, unique naming of your check-in stations can assist in support and troubleshooting. Depending on your setup, you may have volunteers setting themselves up, or key leaders, who create a station called “Bob’s iPad” — that may be unique to him, but with X campuses, there might be several Bob’s who do check-ins, so asking people to use their Full Name might be helpful when something involving that Station goes bad. Similar for campus-level resources (versus personal resources), its easy to name things like “Kids Laptop 1” thinking locally only, but adding a campus prefix (e.g. AA Kids Laptop 1) will help the core team to troubleshoot more specifically.
Giving
As the Planning Center team suggests in their training and videos, setting up a per campus Fund makes it easier for people to give directly to their campus needs. This works well for us, as we have each campus as a financial sub-unit with its own Giving -> Expenses. For some Multi-campus churches that operate as wholly separate entities, or just manage different Chart of Accounts (COA) for each entity, this model may be harder to utilize. When we first started looking at migrating from CCB to PCO, our team wanted PCO to represent the COA we had in place and were using in CCB. But as we looked at it, we really weren’t managing all of finances in CCB anyways — this was being done in a full financial package external to our Chms — so as we clarified this, requiring it to look like our COA while just managing Giving became a non-issue for us.
For Text-to-Give, it’s also easy to set up a unique per campus designator within the Fund set up for people to direct their giving to their specific campus. One issue we ran into: when setting up and testing with our primary campus, we set up this campus fund as the default fund, and also with no Text-to-Give designator. PCO may change this, but right now for any Text-to-Give user, they have to give an initial text amount (could be a $1) to the default fund to get Text-to-Give setup completed. This means that any Text-to-Give user at our other campuses will always give $1 to the primary campus, and if they forget the campus designator, their gift goes to the primary campus rather than theirs. Example: if someone forgets and texts “$50” rather than “$50 centerville”, the funds they intended to go to Centerville goes to the default fund and campus. For this reason, we changed the default fund to a cross-campus general fund, which could catch these if they occurred, mitigating the potential impression that the primary campus had some priority or unfair advantage.
Registration
Depending on your setup, your campuses may be highly decentralized — with events being almost exclusively campus-specific — or highly centralized, or a bit of both. For us, we do a lot of cross-campus events, for which PCO Registrations was perfect! Coming from CCB, if we wanted to take attendance at a cross-campus event, we had to create parallel events for each campus (CCB Supports recommended approach). Registrations make this easy, leveraging the Campus enumeration that already exists in the PCO Accounts setup, allowing Events to be associated with a specific campus.
Even so, we found that sometimes teams would create what appeared to be duplicate events in the listing, which were intended for different campuses — but this was not apparent. Having them include the Campus (name or abbreviation) in the event name helped clear up significantly.
People
While PCO Accounts does allow setup of multiple church campuses w/addresses, this table of info is not currently exposed in PCO People so that you can assign people to their respective campuses. This is both positive and negative — would love to be able to view/filter People views by campus, and use a common core table (in Accounts) to align Campus container across People/Giving/CheckIns/Services/etc. However, coming from CCB where Campus containers were rigid/fixed/immovable and therefore a problem, PCO Peoples design allows for a far more open use, where you can leverage campus data, or ignore it.
For us, we simply created a Custom Tab (Campus Data) and Field (Campus) with a pulldown of the preconfigured campus names. This is then available to Lists for filtering as needed. Since it is a custom tab, it is then one more click down from the Persons profile page — hoping that Planning Center makes the Profile page configurable one of these days so we can remove the BIG Age block in the middle (which some of the older staff dislike), and replace it with the Campus field — this would be far more useful for us.
Interestingly, when Planning Center rolled out Workflow organization with categories and campuses — which makes workflow management across multiple campuses much easier — they did leverage the campuses defined in PCO Accounts. I have seen no word on this, but I am betting they integrate the same into the People Profiles before too long.
Not specifically *in* PCO People, but as noted above, using clear naming for CheckIns locations, Giving funds, Registration events makes some of the views in People clear by extension, such as the Activity roll —e.g. a CheckIn to CampusA is a lot clearer than a CheckIn into “Church”.
I will plan on adding more to this over time but wanted to my initial thoughts online for everyone. If you have additions to this, please comment below!