A church should never discover on Sunday evening that a headline feature in its chosen software does not exist. Before approving any plan, the committee should require a live demonstration of each feature that affects the decision, then record what works now, what is unfinished, and what carries extra cost.
In 1985, Coca-Cola chairman Roberto Goizueta faced a problem in Atlanta that had escaped the company’s extensive product testing. Coca-Cola had replaced its familiar formula with New Coke. Consumers had compared tastes in controlled tests, but the research had not measured what people would feel when the original drink disappeared.
The decision was already public. Production had changed. Customers were calling and writing to demand the old formula. Coca-Cola could defend the launch, or admit that a central part of the offer had been misunderstood.
The company reversed course after 79 days and brought the original formula back as Coca-Cola Classic. Thomas Oliver documents the episode in The Real Coke, The Real Story. The lesson reaches beyond soft drinks: a plan can look convincing in a presentation while leaving out the condition customers care about most.
The Sunday evening discovery
Picture the church administrator preparing for Monday’s committee meeting. The proposal is complete. Prices have been compared. Screenshots are in the presentation. One advertised feature helped justify the preferred plan.
Then she tries to demonstrate it.
The menu item is missing, or the feature turns out to be a future release. Perhaps the pricing page says “AI Analytics,” while the product has no usable analytics feature behind that label. Perhaps online giving appears in the plan comparison, but real card payments are not yet available.
Those are current boundaries ChurchFlow must state plainly. ChurchFlow has real strengths, including member events, groups, bus coordination, QR check-in, notifications, and conference operations proven across roughly 8,752 registrations. Its advertised AI Analytics capability is not available as a working feature today. Online Giving also should not be presented as ready to process real payments.
The administrator now has a credibility problem as well as a software problem. She must revise the recommendation before the committee sees it, explain why the feature was counted, and decide whether the remaining product still meets the church’s needs.
That uncomfortable Sunday evening can be prevented.
Replace feature labels with witnessed tasks
A plan comparison tells you what a vendor calls a feature. A live task shows you what the church can actually do.
Before Monday’s meeting, ask the vendor to complete the exact workflow your team expects to use. If analytics matters, have them open the dashboard, choose a real date range, and produce the report the committee expects. If giving matters, ask them to demonstrate the full payment journey, including confirmation, reporting, refunds, and settlement.
Use a simple evidence table with four columns:
- Write down the task the church needs to complete.
- Record who demonstrated it and when.
- Mark it as available, limited, unfinished, or unavailable.
- Note any dependency, additional charge, or manual step.
Screenshots can support the record, but they should not replace the demonstration. A polished mock-up cannot prove that a payment settles or that a report contains usable data.
This is the same procurement discipline explored in The Two Unfinished Features a Church Pricing Page Must Reveal Before Monday and Efua’s Vague Pricing Pages. One Wrong Plan Could Mean a Year of Spreadsheets..
Decide using the product that exists today
An unfinished feature does not automatically disqualify a product. The committee may decide that reliable event registration, groups, transport coordination, QR check-in, and targeted updates solve the church’s immediate problem. That can be a sound decision, provided the missing capability is removed from the business case.
Treat roadmap promises separately. Record the promise, but assign it no value in the current score. Do not sign a longer contract, select a higher plan, or announce a member service because a future release has been mentioned.
This protects both sides. The church makes a decision it can defend. The vendor earns trust by describing the present product accurately.
Put the correction on Monday’s first slide
Coca-Cola’s 1985 reversal worked because the company eventually responded to what customers were actually telling it. Defending the gap would not have restored confidence in the missing original formula.
The church administrator can make the same kind of correction before the meeting begins. Her first slide should say which advertised feature was unavailable, how the evaluation changed, and whether the remaining product still deserves consideration.
Then she should attach the evidence table to the meeting notes. One honest correction on Sunday evening is far cheaper than explaining an unusable purchase months later.
Comments
No comments yet.