Two Roles, One Record, Zero Confusion
The person sitting across from you at the kitchen table after Sunday service is simultaneously a church council member you coordinate with on community events, a prospect you are working toward a life insurance conversation, and someone whose wife's birthday is in three weeks. These three relationships require three completely different mental modes, and maintaining all of them simultaneously, for a roster of 200 families, is where most council-based outreach breaks down.
The standard approach is a contacts app for phone numbers, a spreadsheet for insurance pipeline, and memory for everything pastoral. None of these systems talk to each other. The spreadsheet does not know that this prospect is also a council associate. The contacts app does not know you have a note about their children from six months ago. Memory is not a system.
Holding the Full Household
The record structure here is organized around the family unit, not the individual — which is the correct axis for both church community management and insurance outreach. NAME Family as a last-name anchor, Member first as the primary contact, and SPOUSE as a discrete field mean you can address both people correctly in conversation without improvising.
The dual birthday fields — Member-bday and SPOUSE-bday — are the first place most CRM structures fail. A prospect CRM built for individuals ignores the spouse entirely. That is the wrong model for whole-life or family health conversations, where the spouse's age and birthday are often more relevant to underwriting than the member's. Having both birthday fields visible on the same record means you see the upcoming anniversary, the spouse's birthday, and the member's birthday without opening a second contact entry.
The CHILDREN field as free text handles the complexity that structured fields cannot. Children's situations — ages, school status, special circumstances — change too rapidly and vary too widely to fit a fixed schema. A free-text note field used consistently is more useful than a structured field used inconsistently because the schema was too rigid to capture what actually mattered.
Member Type Is the Pipeline Classifier
The MEMBER TYPE multichoice — Insurance, Client, Associate, Prospect — is doing the work that a conventional CRM's deal stage field does, but adapted for a relationship that spans both professional and community dimensions.
A Prospect is someone you have identified as a potential insurance client but have not yet engaged in that specific conversation. A Client is someone with an active policy. An Associate is a referred contact or someone in the council network who might become either a prospect or a referral source. Insurance is a category that may capture a different classification — policy type or relationship origin — depending on how the user interprets it.
The key is that these categories are multichoice, not single-choice. A council member who is also an active client and who referred two other prospects holds all three tags simultaneously. Filtering by any single tag gives you a clean working list without requiring you to maintain separate records for the same person in different roles.
COUNCIL and COUNCIL CHURCH operate as organizational location fields that connect the individual to their specific council body. For an agent working across multiple parishes or lodge councils, this is the field that prevents cross-contamination — knowing which council a prospect belongs to determines the relationship context for every subsequent interaction.
The Business Card Sitting in Your Database
The Card image field captures the physical business card from the initial meeting — the one that has the direct line written in pen on the back, the title that does not match the standard council position listing, the home address handwritten beneath the printed work address. Scanning it at intake and attaching it to the record preserves context that would otherwise evaporate the moment the card gets filed in a drawer that never gets opened again.
The combination of PICTURE (face recognition in field settings) and Card image means that by the time you are standing in a church foyer trying to remember which of the three men named Joseph is the one you had the insurance conversation with last month, you can pull the record and have a face, a name, a position, a birthday, and the last note you wrote — all in under ten seconds.