Questions to ask during a church management software demo

The short answer

Ask the vendor to complete your church’s work live using a small set of representative people and transactions. Do not spend the hour watching a polished tour. Score each task from zero to three, write down every workaround and promised feature, and require an export before the demo ends.

The best product is not necessarily the one with the most features. It is the one that completes critical workflows with the least risk, duplicate entry, special knowledge, and dependence on features that do not exist yet.

Use one scorecard for every vendor

Choose five workflows that matter most, label each critical, important, or optional, and use the same scale in every demo:

• 0 — cannot complete the task or requires another product.
• 1 — possible through manual duplication, a fragile workaround, custom development, or an uncommitted roadmap item.
• 2 — supported, but needs configuration, training, an integration, or a higher plan.
• 3 — completed live with representative data by the person who would own it at your church.

Multiply critical tasks by three, important tasks by two, and optional tasks by one. Keep cost, migration risk, support, and contract terms as separate columns. A product that fails a child-safety or finance requirement should not win on an averaged feature score.

Give the vendor a small but difficult sample

Prepare fictional or safely anonymized data that resembles your edge cases. Never send unprotected child, pastoral, medical, payment, or donor data for a sales demo.

• Two adults and two children in one household, with different last names and contact preferences.
• Two people who share a name, plus one likely duplicate with an old email.
• A guest who submits a form twice and later becomes a volunteer.
• A volunteer on two teams, unavailable one weekend, who declines another request.
• A donor whose payment email differs from the email on the household record.
• A child with a pickup restriction, an allergy note, and two authorized guardians.
• Staff, ministry, finance, check-in, and volunteer users who need different permissions.

People, households, forms, and follow-up

1. Import the sample people. Which fields, relationships, notes, consent records, and history cannot be imported?
2. Find and resolve a duplicate without losing activity or giving history.
3. Put people with different last names in one household and explain household communication and statements.
4. Submit a public form for an existing person. Does it update, suggest a match, or create another record?
5. Create a follow-up task from that submission, assign it, complete it, and show the history on the person.
6. Find everyone who meets three conditions, save that segment, and use it without a spreadsheet export.
7. Show who can view and edit sensitive notes, child details, contact information, and consent.
8. Export person, household, form, note, task, and activity fields. Which related records or attachments are omitted?

Volunteer scheduling and service planning

1. Collect availability, then prevent a request from going to someone who marked themselves away.
2. Schedule one person on two teams and show the warning or workload view a leader receives.
3. Send a request, decline it as the volunteer, fill the gap, and show the audit trail.
4. Find everyone who has not responded for Sunday and remind them without messaging people who replied.
5. Copy a service plan, change one week, and prove the change does not rewrite the template or past services.
6. Show what a volunteer can do on a phone without administrator access.
7. Explain how training, age, qualification, or background-check status limits who is scheduled.

Giving, reconciliation, and statements

1. Record an online gift whose payment email does not match the donor profile. Show matching and correction.
2. Split one gift across funds, refund it, and show the resulting reports and donor history.
3. Reconcile gross gifts, processing fees, refunds, and the expected deposit without repairing a spreadsheet.
4. Move a misattributed gift between people or households and show who can see the change.
5. Generate a household statement, inspect fund treatment, then correct and regenerate it.
6. Show what happens to recurring gifts, saved payment methods, donor history, and year-to-date totals during migration.
7. Export transactions, funds, fees, batches, refunds, attribution, and statement history in usable fields.
8. State every platform, processing, subscription, messaging, statement, support, and migration fee at our expected use.

Children’s check-in, attendance, and safety

1. Check in the sample family on the devices, printers, label sizes, and network you expect to use.
2. Register a new family at the station without creating duplicate adults or children.
3. Show allergy, room, capacity, guardian, pickup, and custody controls relevant to your policy.
4. Explain what happens when the internet, printer, tablet, or volunteer login fails.
5. Show secure checkout, a lost security code, an unauthorized pickup attempt, and the audit history.
6. Prove a check-in volunteer cannot browse giving, pastoral, or unrelated household information.
7. Export attendance and check-in history with dates, events, locations, rooms, and person identifiers intact.

Migration, ownership, security, and support

1. Who performs migration, what formats are accepted, how many test imports are included, and what is excluded?
2. Which records can we export ourselves, in what format, and which require support or a fee?
3. Who owns our data, backups, files, phone numbers, domains, processor relationship, and integrations if we leave?
4. How are administrator actions, permission changes, exports, merges, financial corrections, and sensitive views audited?
5. What authentication, multifactor, backup, incident, deletion, and retention controls are available?
6. Where is data processed, which subprocessors are involved, and what agreements can we review?
7. What support channel and response target applies to a Sunday check-in or giving failure on our plan?
8. What requires services, a partner, development, an integration, or a higher-priced tier?
9. What does cancellation require, when does access end, and how long do exports remain available?

Demo answers that should lower the score

• “It is on the roadmap” without a generally available feature you can test.
• “You can build a custom report” when the need is a routine operational view.
• “Our implementation team handles that” without scope, price, sample output, or an owner.
• “It integrates” without showing direction, frequency, matching, failure handling, and record ownership.
• “You can export your data” without producing an export with related records and stable identifiers.
• A workflow demonstrated only from an all-powerful administrator account.
• Security, support, pricing, or cancellation promises that do not appear in reviewable terms.

How to decide after the demos

Reject any option that fails a non-negotiable safety, finance, ownership, or export requirement. For the rest, compare weighted workflow score, three-year cost, migration effort, staff change, support, and contract risk. Record the assumptions behind each score while the demo is fresh.

Ask the people who will operate the system—not only the buyer—which option they can use reliably on a busy Sunday. Before signing, repeat the most important tasks yourselves and attach promised exceptions, services, pricing, and data terms to the agreement.

A necessary disclosure

Sanctuary publishes and competes in this category, so this is not an independent ranking. Use the same scorecard on Sanctuary. Ask us to show the difficult cases, produce exports, explain limits, and distinguish what works now from what is planned. The process is useful only when every vendor faces the same evidence standard.