The Feature That Failed Friday’s Test, and What It Could Cost the Church

A church administrator should pause signup when a headline feature cannot complete the job the committee expects. Confirm the feature in a live, end-to-end test, record the result, and revise the buying recommendation before anyone signs.

In 2010, Walgreens was considering a partnership with Theranos. Consultant Kevin Hunter wanted to examine the company’s blood-testing technology before Walgreens committed, but Theranos restricted his access to its laboratory. Hunter warned Walgreens executives that the lack of access made proper validation impossible.

The outcome was still uncertain. Walgreens could insist on evidence and risk losing the opportunity to rival CVS, or proceed with a company whose central claim had not been independently verified. As John Carreyrou documents in Bad Blood, Walgreens moved ahead.

The Friday discovery that changes the recommendation

Bring the same problem into a church committee review.

The administrator has spent weeks comparing platforms for a 500-plus-member church in Accra. She has mapped member groups, event registration, transport coordination, communications, giving, and check-in. Her recommendation is due after the weekend.

Then the committee asks for a demonstration of one headline feature.

The feature appears in the plan description. It helped the platform survive the first round of comparisons. Yet the live test cannot complete the expected task. Perhaps it is still under development. Perhaps the label describes a configuration flag rather than something a church can use. Perhaps the demonstration depends on a manual workaround that was never disclosed.

The administrator now has two risks. The church could buy software on a false assumption. She could also lose the committee’s trust by defending a recommendation that no longer matches the evidence.

This is the point where procurement discipline protects credibility. A careful administrator does not hide the discovery or dramatize it. She changes the recommendation.

For ChurchFlow, that distinction matters today. AI Analytics should not be treated as an available capability, because the current Premium-tier label is not backed by a usable feature. Online Giving should not be presented as ready to process real payments while card capture still uses a mock payment method. Those limits belong in the review record before signup.

Test the outcome, not the menu label

A feature list tells you what a vendor calls something. A workflow test tells you what your church can accomplish.

If the committee expects giving, ask someone to complete a payment using the intended payment method and confirm what appears in the administrative record. If it expects analytics, ask the system to answer a planning question using real or approved sample data. If it expects event check-in, register an attendee, produce the code, scan it, and confirm that attendance updates.

The test should follow one complete path:

1. Start with the same access level a real member or volunteer will have.
2. Complete the task without intervention from the vendor’s technical team.
3. Confirm that the expected record, message, or status appears for the administrator.
4. Note every workaround, unavailable step, and dependency.
5. Save the result beside the purchase recommendation.

This approach also prevents one missing feature from unfairly discrediting everything else. ChurchFlow has working capabilities that can be evaluated on their own evidence, including conference registration, QR check-in, GPS-validated self-check-in, group management, bus coordination, and administrative visibility. Its conference operations have handled roughly 8,752 registrations. Those are stronger buying signals than an impressive label that cannot survive a demonstration.

For a broader comparison process, use the plain-language church software pricing framework. It helps separate published price, member limits, messaging costs, setup work, and present availability.

Rewrite the recommendation without losing face

The administrator’s strongest move is a short written correction:

“The committee expected this plan to include a usable analytics feature. Our review did not confirm that capability. I recommend evaluating the platform on the features demonstrated successfully and excluding analytics from the purchase case until it passes an agreed test.”

That statement protects the church and the administrator. It also gives the vendor a fair path forward. A product under active development can still be a sensible choice when the available capabilities solve the immediate problem and the missing capability is clearly documented.

Three labels help:

• Available now means the church completed the workflow successfully.
• Limited means the workflow works with a disclosed constraint or manual step.
• Planned means the feature should carry no weight in the current purchase decision.

The Free, Standard, and Premium plan guide can help committees apply those labels across tiers.

Make evidence the condition for signup

Walgreens eventually opened Theranos testing locations, then ended the partnership after the technology and testing practices came under scrutiny. The problem began earlier, when restricted access prevented proper verification and competitive pressure still pushed the agreement forward.

A church software purchase carries smaller stakes, but the mechanism is familiar. A compelling claim creates momentum. A committee fears delaying the project. The person raising the unresolved issue risks appearing difficult.

Put one sentence into the approval record before Friday ends: “Signup proceeds only after every purchase-critical feature has either passed its workflow test or been removed from the business case.”

That sentence gives the administrator something stronger than confidence. It gives her evidence.