Every church I’ve worked with eventually asks the same question, usually in a staff meeting, usually after someone leaves and nobody saw it coming: how engaged are our people, actually?
It’s a good question and a dangerous one. Good, because the answer is knowable and most churches are flying on impressions. Dangerous, because the moment you can measure engagement you can rank people by it, and the distance between “here are twelve families worth a phone call” and “here is a leaderboard of our congregation” is one careless spreadsheet column.
This is a long piece about how to build the measurement honestly in Planning Center, and a longer one about how not to let it turn into a scoreboard. If you only read one section, make it the one about scoring pitfalls. The mechanics are the easy part.
What “engagement” is made of in Planning Center
Engagement isn’t a thing your database stores. It’s an inference you draw from four separate behaviors, each of which lives in a different Planning Center product:
Attendance is check-in records in Check-Ins. Per person, per event, per date. This is your highest-frequency signal: weekly, granular, and (for the people it covers) fairly reliable.
Giving is donation records in Giving. Recency, frequency and consistency matter far more here than amount. Someone who gives $25 monthly without fail is a more engaged household than someone who gave $5,000 once at Christmas, and any measure that reads amounts will tell you the opposite.
Serving is scheduled and confirmed positions in Services. It is a visible commitment of time, but a change in serving can mean workload, availability, health, family circumstances or disengagement; the schedule alone does not tell you which.
Belonging is group membership in Groups. It is the most binary of the four and useful evidence of a relationship beyond the weekend, without being proof of somebody’s future attendance.
Four signals, four products. You’ll notice what’s missing: there’s no fifth product called Engagement, and there’s nowhere in Planning Center that puts these four numbers on one row next to a person’s name. That absence is the whole subject of this article.
Each product will report on itself perfectly well, and the complete guide to Planning Center reports walks through what’s built in per product. Check-Ins will give you headcounts and per-event attendance. Giving will give you fund totals and donor statements. Services will give you a team matrix. Groups will tell you who’s in what.
None of them can tell you that the Alvarez family checked in eleven times this quarter, gave in April but not since, came off the parking team in February, and isn’t in a group. That row doesn’t exist anywhere for every person at once. A single profile’s Activity tab will show you that one person’s check-ins over the last twelve months, and Giving will show you that one person’s history, but neither of them works across a roster. Assembling it is the job.
Why this is a join, and where Planning Center stops
Planning Center is a suite of separate products that share an account and a person record. That architecture is why each one is fast and focused and doesn’t buckle under the weight of the others, and I’d defend the decision. It’s a big part of why churches love the software.
Most detailed reports still live inside one product. But it isn’t true that Planning Center won’t cross between them, and there are at least three surfaces that do now. Home can place widgets from several products on one dashboard. People Lists can combine conditions from products including Check-Ins, Giving, Groups, Services and Registrations. And Planning Center’s own AI connector will answer a cross-product question live, in a tool like Claude or ChatGPT, reading across People, Services, Groups, Registrations and Check-Ins.
That third one deserves more attention than it currently gets. Planning Center’s published example question is “who’s scheduled to serve this Sunday but isn’t in a small group,” which is very nearly the example I was about to use with the products swapped. It’s scoped to the asking person’s permissions, and it keeps no copy of your data.
It also keeps no history between questions, and it does not cover Giving. Both of those matter enormously here. Engagement is a cross-product question, and every useful version of it has an “and” in it: attends and doesn’t give, gives and doesn’t attend, serves and isn’t in a group. Two of those three turn on giving. A surface that can’t see Giving can answer part of this model and then stop.
So the wall isn’t joins. Planning Center joins across products in three different ways, and the connector in particular is better at the ad-hoc version of this question than a spreadsheet will ever be. The wall is memory and Giving. Nothing in the suite holds four measurements beside a person’s name, compares them against the same person three months ago, or reaches into Giving while doing either. That is where the workbook starts earning its keep.
People Lists get closest. They’re the reporting workhorse of the suite, and the rule builder genuinely does reach outside People: conditions are drawn from products including Check-Ins, Giving, Groups, Services and Registrations as well as People itself. The catch is that each condition is gated on permissions in the product it came from, so a children’s ministry director with Check-Ins access won’t see the Giving conditions at all. You either need broad permissions yourself or you add someone who has them as a manager on the list. If you go the second route, know the boundary before you split the work: a rule created by one list manager can be viewed and deleted by another manager, but not edited. Two people maintaining one list will eventually delete and rebuild each other’s conditions rather than adjust them.
But even with the full catalog in front of you, a List gives you membership, not measurement. It tells you who matches a condition right now. Planning Center puts this more plainly about its own product than I would dare to: their common donor lists page notes that a list for people who gave over $100 in a month returns only single donations over $100, not the person who gave $120 across four gifts, and points you at donor reports for cumulative totals. A condition tests rows. It doesn’t add them up.
A List still can’t hold four numbers per person, and it can’t tell you that a household’s pattern is changing, which, as we’ll get to, is the only part of engagement that should ever prompt a phone call. It can now look backwards, but only through one narrow window: since February 2026 the rule builder has was and became conditions, which give you point-in-time snapshots and transitions, on backfilled historical data, for membership type. You can ask who held a given membership type at the end of last quarter and get a real answer. That’s genuinely useful, and it is also the only signal it works for. None of the four this model runs on, attendance, giving, serving and group membership, has an equivalent.
So: spreadsheet.
The manual method: five datasets, one workbook
This works. I’ve built it for churches and I’ve watched churches build it for themselves. Budget most of a day the first time, and about two hours each time after that.
The exports
Pull these from Planning Center, all with the same as-of date so the windows line up:
- People. Your roster. You want person ID, first and last name, household ID, household name, campus, and membership status. The person ID is the spine of everything that follows.
- Check-Ins. Check-in records for the last 12 months, at the person-and-date grain, not a headcount summary. You need one row per check-in, and this is by some distance the hardest of the five to obtain. Read the note below before you promise anyone a twelve-month number.
- Giving. Successful donations for the last 12 months if you only need the current window, or 24 months if you want to compare a full current twelve-month period with the preceding twelve. Use the gift’s received date and a verified stable person mapping; do not assume a donor number or email is the Person ID.
- Services. Scheduled positions for the last 12 months, with the confirmed/unconfirmed/declined status on each. A schedule someone declined is not serving, and counting it as serving will hide exactly the person you’re trying to find.
Plus a fifth if your Groups data is real: Groups memberships, one row per person per group. No single Planning Center export produces that shape. Member lists come out one group at a time, so this tab gets assembled from a stack of per-group exports or pulled from the API.
Export paths move, so confirm yours before you write instructions for your team, but the shape is stable. People comes out of People → Actions → Import & Export CSV, or from any List via the download icon once you’ve set the columns you want; both need the Can export CSVs and reports permission. Giving is the genuinely straightforward one, exporting its own donation records at the grain described above.
Check-Ins is the awkward one, and I’d rather you heard it here than found out on a Thursday afternoon. Its reporting is organized by person rather than by check-in, and it reaches back 53 past sessions, which for a weekly service is about a year. That is sitting right on the ceiling of the twelve months I asked for above, with nothing spare. The only CSV that gives you a true row per check-in is the activity feed on an individual profile, one person at a time, which is not a roster. If you want twelve months at person-and-date grain for everyone, the honest routes are the API or a standing habit of exporting on a schedule and accumulating the results yourself. If you’re doing this once by hand, take what the 53 sessions give you and write the real window at the top of the sheet rather than claiming a year you don’t have.
Name the exact export surface in your instructions. In Services, the service-type People report accepts a timeframe, shows each person’s plan-level scheduling status and attendance, and downloads as CSV; the generic People-page CSV is a different, profile-oriented export. Groups has member and attendance reporting of its own, including multi-group attendance reports, though the member lists themselves still come one group at a time. In both products, inspect a real CSV before building formulas: confirm whether a row represents a person, membership, plan assignment or attendance record, and confirm which stable identifier is actually present.
The workbook
Six tabs. Five are raw exports you never touch; paste over them next quarter and everything downstream recalculates. The sixth is the one you actually read.
people Person ID | First | Last | Household ID | Campus | Status
checkins Person ID | Event/Session ID | Date
giving Person Key | Date Received | Fund | Amount | Included?
serving Person ID | Plan ID | Date | Team | Normalized Status
groups Person ID | Group ID | Group Type | Role | Joined
engagement ← the sheet you readPut one fixed as-of date in $H$1; do not use TODAY() if you want the same pasted inputs to reproduce the same answer next week. Normalize the real Services export values (C or Confirmed, for example) to Confirmed. In Giving, make Included? an explicit TRUE only for the successful, non-refunded rows your metric definition includes. Don’t go looking for a status column on the groups tab: a Groups membership either exists or it doesn’t, and the only distinction carried on it is whether the person is a member or a leader. Counting rows per person is the whole calculation, which is why that column is a plain COUNTIF. Then start the engagement tab with one row per person and use formulas like these:
Last check-in =LET(n,COUNTIFS(checkins!$A:$A,$A2,checkins!$C:$C,"<="&$H$1),
IF(n=0,"",MAXIFS(checkins!$C:$C,checkins!$A:$A,$A2,checkins!$C:$C,"<="&$H$1)))
Check-ins, 90d =COUNTIFS(checkins!$A:$A,$A2,checkins!$C:$C,">="&$H$1-89,
checkins!$C:$C,"<="&$H$1)
Last gift =LET(n,COUNTIFS(giving!$A:$A,$A2,giving!$E:$E,TRUE,giving!$B:$B,"<="&$H$1),
IF(n=0,"",MAXIFS(giving!$B:$B,giving!$A:$A,$A2,giving!$E:$E,TRUE,giving!$B:$B,"<="&$H$1)))
Gifts, 12 months =COUNTIFS(giving!$A:$A,$A2,giving!$B:$B,">"&EDATE($H$1,-12),
giving!$B:$B,"<="&$H$1,giving!$E:$E,TRUE)
Serves, 180d =COUNTIFS(serving!$A:$A,$A2,serving!$C:$C,">="&$H$1-179,
serving!$C:$C,"<="&$H$1,serving!$E:$E,"Confirmed")
Groups joined =COUNTIF(groups!$A:$A,$A2)Two rules that will save you a rebuild.
Match on a verified stable ID, never on name. Name matching breaks on Mike versus Michael, on a marriage, and on every household where the gift is recorded under one spouse some years and the other in others. Check the actual export headers before assuming Giving or another product includes the People ID; donor number and email are not safe substitutes. If no common ID is present, build and test an explicit mapping table or use API records that carry stable resource IDs.
Roll up to the household deliberately, not with a blanket SUM. Giving is often recorded against one household member, children generate many check-ins, and another adult may serve. Take the maximum of recency dates. For attendance, count distinct household-plus-event/session keys so three children checked into the same service do not become three household attendances. Sum transactional counts only after deciding that their row grain matches the question. If a person belongs to more than one household, document which household receives the activity rather than duplicating it into both.
That’s the method. It genuinely works, and if you never read another word about analytics software, that workbook will make your church better at noticing people.
The part where it goes wrong
Now the important section.
The moment you have four numbers per household, someone will want to combine them into one number. It’s an irresistible instinct: weight the four signals, sum them, sort descending, and now you have an engagement score. I’ve built these. I’ve also watched what they do to a staff culture, and I want to be precise about the failure modes, because most of them are invisible until they’ve already done damage.
Your data measures visibility, not devotion
This is the big one, and it’s structural rather than fixable.
In most churches I’ve worked with, adults do not check in. Children do. Which means your attendance signal, the highest-frequency and most trusted input in the whole model, largely measures being the parent of a small child. An empty-nest couple in the third row every Sunday for nineteen years may generate zero check-in records, forever.
Before you score anyone, compute one number: what percentage of your adult roster produced any check-in at all in the last twelve months? If it’s under half, you don’t have an attendance signal, you have a young-families signal, and any score built on it will systematically rank faithful older members as disengaged. That’s not a rounding error. That’s the model being wrong about the exact people most likely to be quietly carrying your church.
The same holds for the other three. Anonymous or unmatched cash is invisible at the person level even when the donation itself is recorded in Giving. Serving arranged over text never reaches Services. A ministry that meets weekly but was never entered into Groups doesn’t exist to your model. Every one of these gaps looks identical to disengagement in a spreadsheet, and every one of them is actually a gap in your data collection.
Absence of data is not evidence of absence. Write that at the top of the sheet.
A score is a values statement wearing a lab coat
Decide that giving is worth 30% of engagement and you have just made a theological claim about your church, in a formula, without a conversation. Weight serving heavily and your model will tell you that a woman recovering from surgery has fallen off, which is true of her calendar and false of her faith.
There’s no neutral weighting. There’s only a weighting somebody chose. So choose it out loud, with the people who’ll act on the output in the room, and revisit it when it starts producing names that make everyone uncomfortable. That discomfort is usually the model being wrong, not the congregation.
Labels stick harder than numbers
The most damaging thing you can do with this work is write the word “disengaged” next to a human name in a shared system. Once it’s in a field, it’s a fact. It shows up in a merge field, it gets read by a volunteer who doesn’t know the context, it survives long after the season that produced it, and it changes how someone is greeted on a Sunday.
I care about this more than is strictly professional, because I was that person once. As a kid I fell through the cracks at my own church, not from any malice, just an absence of anyone with a system for noticing. The whole reason to build engagement measurement is so that fewer people have that experience. Building it in a way that formally categorizes people as low-value is the precise inversion of the point.
So: the output is a list of people to reach out to. It is never a rating attached to a person. If your implementation produces something a person could be shown and be hurt by, you’ve built the wrong thing.
A neutral meter, not a scoreboard
Here’s the framing I’ve landed on after a lot of arguing about it, including inside our own product.
An engagement measure is a meter, not a score. A meter has no opinion about you. A fuel gauge doesn’t judge the car. It tells you how much is in the tank so you know whether to stop, and the reading is about the tank’s state right now, not the car’s worth.
Practically, that means a few concrete design choices:
- Show a level, not a rank. Sorting your congregation descending by a number is a scoreboard, and the bottom of it is a list of people you’ve implicitly written off. Bands, a handful of levels with plain names, resist that in a way a 0-100 number never will.
- Strip the color where you can. We spent real time on this internally and ended up removing the traffic-light hues from our own engagement badge, leaving one neutral shape that fills up more or less. Red next to someone’s name does something to how you read them before you’ve read anything else. Reserve color for one thing only: this needs a human.
- Lead with direction, not level. A household at a low level who’s been at that level happily for a decade is not news. A household that dropped two levels since March is the only thing on the sheet worth interrupting someone’s week for. Change is the signal. Level is context.
- Never surface it to the congregation. No engagement number in a Church Center profile, no tier in an email merge field, no gamification. Ever.
The signal is a reason to ask, not a conclusion
The most useful sentence I know for this whole discipline: the data tells you who to ask, and nothing else.
Every household on your list has a story the spreadsheet cannot see. New baby. Job loss. A shift change that killed Sundays. A parent dying two states away. Chemotherapy. A conflict with a staff member nobody told you about. Sometimes a genuine and considered decision to leave, which people are allowed to make.
The data can’t distinguish any of those. It’s not close to being able to. What it can do is put fifteen names in front of a human being who knows them, at a moment early enough for a conversation to matter, and that is an enormous amount of value for something so modest.
Which suggests the last rule, and it’s an operational one: give the list to whoever knows those people, not to the senior pastor and not to a mail merge. A group leader will look at fifteen names and tell you in thirty seconds that four of them are fine, three of them she already knows about, and one of them she’s been worried about for a month and is relieved someone else noticed. That filter is worth more than any weighting you could tune.
Two questions worth defining carefully
If a full engagement model is more than you want to maintain, these two person sets are useful on their own. People Lists can produce the current names; the workbook earns its keep when you also need counts, household rollups or movement over time:
Attends regularly but isn’t in a group. Filter for check-ins in the last 90 days above a threshold you define, and a group count of zero. Treat the result as an invitation pool after checking whether group membership and adult attendance are recorded consistently. Pair it with the attendance tracking walkthrough if you need the Check-Ins export to hold up over time.
Serves or gives but hasn’t attended. Recent serving or giving activity, no check-in in 60 days. This is a reason to check the underlying records and ask a person what changed, not evidence that they are leaving. The serving reports guide covers the Services side, and the Giving reports guide covers the Giving side.
Making it standing rather than annual
The honest weakness of the workbook isn’t the effort. It’s that the answer expires.
Build it in September and by November it describes the September snapshot unless somebody refreshes it. A manual workbook can be maintained monthly, quarterly or annually; the honest operating cost is that its trend only exists when someone repeats the process on schedule and preserves the prior answers.
That’s the gap Parable fills. It reads People, Check-Ins, Giving, Groups and Services out of Planning Center every night and keeps them joined on a shared person and household key, so the engagement row I described above is just there: four signals per household, on one line, with an arrow showing which way it’s moving since last month. No exports, no lookups, and nothing to rebuild in November.
Deliberately, it’s a meter and not a scoreboard: neutral levels rather than a number you can rank people by, and color reserved for the handful of households where something actually changed. You can ask it “who attends regularly but isn’t in a group” in plain English and get back a list of names, which is the same output the spreadsheet gives you, just without the day.
The reason to measure any of this isn’t the measurement. It’s that churches are full of people who assume someone would notice if they stopped coming, and are often wrong about that, not because anyone stopped caring, but because caring at scale requires a system, and most churches don’t have one.
A spreadsheet with four columns is a system. It’s not a sophisticated one. But it’s the difference between finding out in March and finding out in September, and for the family in question that gap is the whole thing.