A care team dashboard is one of those things almost every church team eventually asks for and almost no team gets right on the first try. The chair wants a single screen that tells him whether the congregation is being shepherded. The pastor wants to know which families are quietly slipping. The board wants a number it can read in five seconds before the meeting starts. The deacons want a tool that does not punish them for logging a phone call from the car. Most dashboards end up trying to satisfy all of those people at once and serve none of them well.
This post is a working answer to the simpler question buried inside all of that. If you were building a care team dashboard from scratch, knowing it had to fit on a single screen and survive contact with a small team of volunteers who use it for ten minutes a week, what would you actually put on it. The short answer is six things, and most of the rest of the work is making sure the dashboard does not creep beyond them.
Why the Dashboard Matters Before the Features Do
Before talking about views, it is worth saying out loud what the dashboard is for. The job of a care team dashboard is to make the right families visible at the right moment. That is the entire purpose. Every other feature is in service of that one outcome. A dashboard that looks impressive but does not surface the household that has not been contacted in eighty-three days is not doing its job. A dashboard that looks plain but opens to that exact household on Sunday afternoon is doing the only job that matters.
The reason this framing matters is that most teams design their dashboard around the data they already have rather than around the questions they actually ask. The data they have is whatever lives in the spreadsheet or ChMS today. The questions they ask are about coverage, drift, overdue families, open follow-ups, and quick logging. Those questions are not the same shape as the data, which is why the spreadsheet stops feeling useful around month four. The dashboard is the place where the team finally builds the views the questions need.
The Coverage View Has to Open First
If only one screen could exist, it would be the coverage view. The coverage view is a single list of every family in the congregation, ordered by how long it has been since anyone on the care team last had a meaningful contact with them. The family at the top of the list is the one most overdue. The family at the bottom was contacted yesterday. The chair opens the dashboard, sees the top of the list, and knows in five seconds where the team needs to spend the week.
The reason this view has to be the default is that the families a team most needs to see are exactly the families that are easiest to forget. A household in active crisis is on everyone's mind already. A household that quietly stopped attending six weeks ago is not. The coverage view forces those quiet ones up to the top of the screen where someone will see them. A church care coverage dashboard, done well, is essentially this view plus the supporting pieces that make it actionable.
Family-Level View, Not Member-Level
Most ChMS tools are built around the individual member. The contact record, the profile, the notes, the workflow steps all attach to a person. That is fine for membership tracking and for things like baptism follow-up, where the unit of work really is a single person. It is the wrong unit for pastoral care. The unit of pastoral care is the household. Deacons are assigned families, not individuals. A visit covers a whole home. A meal goes to a kitchen, not a contact record. A drift pattern shows up at the family level long before it shows up at the member level.
A care dashboard that lists members instead of households makes the team do mental arithmetic every time they open it. They see three contact records and have to remember that two of them are spouses in the same home, which means that household has actually been contacted twice in two weeks while the family next door has been silent for ninety days. The dashboard should do that arithmetic for them. Every row is a household. Every contact is attributed to the household. Every overdue signal reflects the family as a whole.
A Contact History You Can Read in Two Minutes
The third piece is a contact history that any team member can read in two minutes and understand the relationship. When a deacon is reassigned a new family, when a pastor steps in for a hospital visit, when the chair is preparing for a board meeting, the question is always the same. What has been happening with this household. The dashboard should answer that question with a clean reverse-chronological list of contacts, each with a short note, the contact type, the date, and who made the contact. Nothing more.
The reason this matters is staff and volunteer turnover. The deacon who has been shepherding the Johnson family for three years carries that history in his head. When he rotates off the board, that history is gone unless the dashboard captured it. The team that has been writing a one-line note after each contact for those three years has a transferable record. The team that has been relying on memory has to rebuild the relationship from zero. A history that takes two minutes to read is the difference between a smooth handoff and a family quietly falling through a gap nobody could see.
The Open Follow-Up Queue
The fourth piece is the open follow-up queue. A follow-up is something that came out of a contact and still needs to happen. The Johnson family asked the deacon to check on their college daughter. The Patel family mentioned they might be moving. The Williams household said the husband's job interview was Thursday. Those are not contacts. They are small promises that need to survive until the next interaction, and they are almost always the first thing a tired team forgets between meetings.
The follow-up queue is the dashboard's memory for the team. Every contact entry has the option to create a follow-up with a date and a short note. The dashboard shows the open follow-ups, ordered by due date, with the family they belong to. When a deacon opens the tool on Tuesday morning, he sees that he promised to call the Williams household after the interview, and he does it. Without the queue, the promise lived in his head along with twenty other things and died there sometime around Wednesday lunch. A regular contact cadence is the rhythm. The follow-up queue is what catches the specific promises in between.
Quick-Log From a Phone
The fifth piece is not a view at all. It is a button. A care dashboard that cannot capture a contact in under thirty seconds from a phone is not going to be used. The reason is the moment the contact actually happens. A deacon makes a phone call from his car after work. He has five minutes before he needs to drive home. If logging the call takes him through four screens, a profile lookup, a dropdown menu, and a paragraph form, he will not log it. He will tell himself he will do it later, and later he will not.
The quick-log path needs to be one tap to the household, one tap to the contact type, one short note, and done. That is it. The dashboard does the rest, including updating the last-contact date, recalculating the overdue queue, and notifying whoever needs to know. The team that builds this correctly stops losing contacts to the gap between intention and the desk. The team that does not build it correctly ends up with a dashboard that looks clean because half the work never made it in. What actually matters in deacon care software almost always comes back to this question of whether the team can move at the speed of real ministry.
Roles, Permissions, and What the Board Sees
The sixth piece is the only structural one. Different people on the team need different views. A deacon should see his assigned families first when he opens the dashboard. The chair should see the whole list ordered by coverage, with the ability to filter to any deacon's portfolio. The pastor should see the same as the chair plus the open follow-ups across the board. The elders, if they look at all, should see a single coverage summary they can read at the top of the board meeting without scrolling.
The temptation here is to build a permission system more elaborate than the team needs. A small church has a deacon role, a chair role, and a pastor role. That is enough. Anything more granular slows down setup, confuses volunteers, and makes the dashboard feel like enterprise software for people who just wanted to know which families to call this week. Three roles, three default views, and a clean way to filter by deacon. That is the structure that holds up at small church scale.
What a Care Dashboard Should Not Try to Be
A care dashboard should not try to be the membership database, the giving record, the check-in system, or the services planner. Those are real and necessary jobs and somebody else's tool does them better. The discipline of staying inside the care slice is what keeps the dashboard light enough for the team to actually use. Every feature added outside the care job pulls the dashboard a little further from the moment of the phone call in the parking lot. A short pastoral care software comparison is sometimes useful here, because it makes clear how the dashboards that try to do everything end up doing nothing well.
The other thing the dashboard should not become is a reporting tool. Reports are useful at the board meeting. They are not useful on a Tuesday morning when the question is which family the deacon should call before lunch. A dashboard buried under filters, exports, and configurable charts stops being a dashboard and becomes a small analytics product. The team does not need a small analytics product. The team needs the coverage view to open first.
What This Looks Like in OurChurchCare
OurChurchCare is built around exactly these six pieces. The home screen opens to the coverage view, ordered by which households are most overdue. Every row is a family, not a member. Tapping a household shows the contact history, the open follow-ups, and a single button to log a new contact in under thirty seconds from a phone. The chair sees the whole list and can filter to any deacon's portfolio. The pastor sees the same plus the cross-board follow-up queue. The elders get a summary at the top of the board meeting without scrolling.
Pricing is flat, the trial does not require a credit card, and the tool intentionally stays inside the care slice. If your current dashboard is built on a spreadsheet that has stopped giving you an honest coverage picture, or a ChMS that lists individuals when you needed families, start a free OurChurchCare trial, import your member list, and watch the coverage view build itself over the next few weeks of normal shepherding.