Ama’s AI Analytics Demo Fails. Her Board Recommendation Is at Risk.

A premium feature should be disclosed as planned until a church can use it, especially when it appears in a paid plan. Clear pricing protects a board’s trust before a demo turns into an uncomfortable discovery.

At 8:40 on a Tuesday morning, Ama sat in the fellowship hall in Accra with her laptop open, a printed pricing page beside the tea she had forgotten to drink. In twenty minutes, she would show her church board why a new member engagement platform could help them manage events, groups, and communication from one place.

She had highlighted one line in yellow: “AI Analytics,” included in the Premium plan.

The board had asked for better attendance insight after their last large event. Ama expected questions about who was registering, who checked in, and which branches were engaging. She had built the demo around that feature.

Then she asked the vendor’s contact a simple question: “Can you show us the analytics screen?”

The answer changed the room before the board members even arrived. The feature was still planned. There was no usable analytics screen, no reporting workflow to demonstrate, and no date she could responsibly take back to the board. Her recommendation was suddenly at risk. If the board felt misled, they could reject the whole platform, including the event registration and QR check-in tools that had genuinely impressed her.

A priced feature becomes a promise

A feature listed beside a plan price carries more weight than a future roadmap item. Buyers reasonably read it as something they can use after subscribing.

That does not mean software teams must hide work in progress. Church technology changes over time, and a roadmap can help leaders see where a product is headed. The issue is placement and language. A planned capability belongs under “Coming soon,” “Beta,” or “Planned,” with a plain explanation of what is available today.

For a church administrator preparing a board recommendation, the difference matters. She needs to distinguish between what can solve this quarter’s problem and what may help later. A vague promise forces her to do that work in front of decision-makers, where trust is hardest to rebuild.

ChurchFlow has real operational strengths that deserve a clear presentation. Its conference registration, QR check-in, bus coordination, and member communication capabilities address practical moments when a church needs accurate information quickly. Those are stronger proof points than an AI label without a working product behind it.

For a related pricing decision, see Church Software Pricing: Why Ama Marked AI Analytics “Confirm Before Purchase”.

What honest disclosure looks like in a demo

The vendor could have prevented Ama’s Tuesday problem with one direct sentence on the pricing page: “AI Analytics is planned and is not available in the current Premium plan.”

That disclosure gives a buyer useful choices. She can select a plan for its current capabilities, postpone a purchase until the feature exists, or ask whether the roadmap timing fits her church’s needs. Each choice is better than discovering the gap during a board demo.

A good demo should separate three categories:

• Available now: features a church can see, test, and use.
• Beta: features available to a limited group, with clear limits.
• Planned: features under development, without being counted as present-day value.

The same rule applies to payment features. A giving screen may look complete while the underlying payment flow is still being prepared. A church should know whether a member can make a real payment before that capability appears in a paid package. What Happens When a Giving Demo Cannot Process a Real Payment? explores that risk from the administrator’s side.

The board needs evidence it can repeat

By 9:05, Ama had put the printout face down and changed her opening slide. She showed the parts of the platform that were ready to discuss: event registration, QR check-in, bus capacity coordination, and targeted updates when travel plans change.

Then she said what she had learned about analytics. “This is planned,” she told the board. “I would not include it in our decision today.”

That sentence cost her a polished selling point. It gave her something more valuable: a recommendation she could stand behind.

Church leaders already carry enough uncertainty when they introduce a new system. Members may need to change routines. Volunteers may need training. A board may ask how the platform will work during a crowded conference or a last-minute transport delay. Product pricing should reduce that uncertainty by showing the truth of the current product, in plain language.

A vendor earns confidence by making the limitations easy to find. Put feature availability beside the price. Mark beta features clearly. Remove unready features from comparison tables until customers can actually use them. If a planned feature influences the buying decision, explain its status in the demo before a buyer has to ask.

Ama left the hall with fewer slides than she had prepared. Her final slide listed the capabilities the church could verify that week, and one line at the bottom: “Review future analytics when it is available.” The board could debate the real decision in front of them.