Adwoa’s Missing AI Analytics. Her Board Recommendation Is at Risk.

A church software pricing page should describe what a team can use today. If a listed feature is unfinished, label it clearly before a finance committee builds a budget, report, or board recommendation around it.

At 7:18 on Sunday morning, Adwoa sat in a quiet church office in Accra with a printed board pack, a blue pen, and one unanswered question. The software plan under review promised AI analytics. She needed one simple chart showing which events brought members back.

The board meeting began after the second service.

Adwoa is a composite church administrator, created to illustrate a procurement risk. She had already told the finance team the premium plan could help leadership understand engagement patterns. Now she could find no report, no setup screen, and no instructions for using the advertised feature.

If she presented the recommendation anyway, the board could approve a plan based on a capability the team could not access. If she postponed, months of preparation might look careless.

She closed the presentation and opened the pricing page again.

The feature was still there.

A missing feature becomes a trust problem

The immediate discrepancy concerned software. The larger issue concerned Adwoa’s word.

Church administrators often translate technical claims for people who will never inspect a product dashboard themselves. A treasurer hears “analytics” and expects reports. A pastor hears “member engagement” and expects a clearer picture of who is connecting with events, groups, and church life. A finance committee sees a feature listed under a paid plan and assumes the feature works.

Each assumption is reasonable.

When the product cannot fulfil the claim, the administrator stands between the vendor’s wording and the congregation’s money. That position carries real weight. Churches may be spending from tithes, offerings, or a tightly controlled operating budget. A small pricing-page discrepancy can therefore raise a much larger question: what else has been presented too confidently?

ChurchFlow currently has this exact credibility gap. “AI Analytics” appears as a Premium-plan claim, while the underlying product does not yet provide a usable AI analytics feature. The honest response is to remove the claim or mark it clearly as planned or in beta until a church can open it, use it, and obtain the promised result.

The same standard applies to every product. A roadmap item belongs on a roadmap. A working feature belongs on a pricing page.

The five-minute test before approving a plan

Adwoa’s blue pen stopped over the words “Recommend Premium.” She replaced them with “Pending feature verification.”

That small edit protected the meeting from a weak recommendation.

Before approving church software, ask the vendor to demonstrate every feature that materially affects the purchase. The test can stay simple:

• Ask where the feature appears in the product.
• Ask someone to complete the main task while you watch.
• Confirm which pricing plan unlocks it.
• Check whether it uses live data, sample data, or a manual workaround.
• Record any dependency, limit, or unfinished step in the recommendation.

A screenshot proves that a screen exists. A live walkthrough shows whether your team can complete the job.

This matters especially when a feature influences the plan choice. If AI analytics moves a church from a lower tier to a higher one, the committee should see the report being created. If online giving affects the decision, the team should verify that a real payment can be processed and reconciled. If SMS is included, confirm what “included” covers and what each additional message costs.

For a wider pricing review, The Two Unfinished Features a Church Pricing Page Must Reveal Before Monday examines how unfinished analytics and payment capabilities should be disclosed. What Happens When “SMS Included” Still Means Paying Per Text? applies the same scrutiny to messaging costs.

Honest labels make decisions easier

Clear product language does more than prevent disappointment. It lets committees compare plans using the same facts.

“Available now” should mean a church can use the feature in its normal workflow.

“Beta” should explain who can access it, what may change, and where support is required.

“Planned” should avoid implying a guaranteed release date unless the company has committed to one.

“Custom setup required” should name the work and identify who handles it.

These labels reduce the effort placed on administrators like Adwoa. They also help vendors hold a more credible sales conversation. A church may still choose a product with unfinished capabilities when the working parts solve an urgent problem. ChurchFlow, for example, can point to real conference operations at substantial scale, including approximately 8,752 registrations, along with bus coordination, QR check-in, groups, and member communications. Those working capabilities provide stronger evidence than an unavailable feature claim.

Honesty can narrow a promise while strengthening the decision around it.

The board pack that changed before service ended

With minutes left before the meeting, Adwoa removed the analytics claim from her recommendation. She kept the software under consideration because the available event and coordination tools still addressed several needs. Her revised note separated what the team had verified from what remained unavailable.

The board received a shorter proposal and a clearer choice.

On Monday morning, Adwoa filed the printed pricing page beside her verification notes. The blue circle around “AI Analytics” remained visible. So did the sentence she had written beside it: “Do not budget from the label. Test the task.”