How to present a membership software change to your board
Boards do not reject software proposals because the software is wrong. They reject them because the proposal reads as a preference rather than a decision.
The staff member presenting has usually lived with the current system's failures for years and finds the case obvious. The board has not, and what reaches them is a recommendation without the evidence that produced it. So they defer it, ask for more information, and the item returns in three months looking the same.
Here is the structure that avoids that, and the four objections you should expect.
What a board actually needs to know
Five questions, and if your presentation answers all five, most of the discussion is over before it starts.
Why now? Boards are suspicious of change without a trigger. "It has always been frustrating" is not a trigger. A contract renewal date, a price increase, a support failure with a date attached, or a specific task that has become impossible is a trigger.
What does it cost in total? Not the monthly fee. The annual cost, the setup cost, the payment processing cost, and what happens to each of those as the organization grows.
What is the migration risk? The board's real fear is that member records get lost or renewals get missed during the change. Address it before they raise it.
What happens if this one is also wrong? A board that approved the last platform is asking how they avoid approving another mistake. The answer is exit terms, and it is the most persuasive part of the case.
Who checked the vendor? Not a character reference. Where the company is, who owns it, how long it has been operating, and what happens to your data if it goes away.
The five-slide structure
Keep it to five. A longer deck invites line-by-line debate about details the board is not equipped to judge.
Slide 1: the current state and what it costs. Two or three specific failures with numbers or dates attached. "The QuickBooks sync has not worked since March and reconciliation now takes six hours a month" beats "the system is outdated". Put the annual cost of the current platform on this slide, including anything paid separately.
Slide 2: what you evaluated and how. Name the platforms you looked at, say what criteria you used, and say why the ones you rejected were rejected. This is the slide that turns a preference into a process. It also pre-empts the board member who asks whether you considered the one their nephew uses.
Slide 3: total cost, current versus proposed. A table with three columns: today, the proposal, and the difference over three years. Include the growth scenario. If your current platform charges per contact or per admin seat, model what happens when the member list grows by 15% or you hire someone, because that is a real cost the board has never seen quantified.
Slide 4: migration plan and timeline. Dates, what moves, who does it, and what the fallback is. Name the risky part rather than hiding it. Every migration has one.
Slide 5: the recommendation and the ask. One sentence of recommendation, then exactly what you need from the board: approval to sign, a budget line, or a decision by a date. Boards approve specific asks and defer vague ones.
The four objections, and what actually answers them
"We just went through this." The honest answer is that the last change did not fail because change is bad, it failed for a reason, and you should be able to name it. If the last platform was chosen on a demo without checking exit terms, say so. A board forgives a diagnosed mistake far more readily than a repeated one.
"Can we afford it?" Reframe to the three-year total including the growth scenario. In many cases the proposal is cheaper, and the reason it looks expensive is that the current platform's costs are spread across several lines nobody has added up. If it genuinely costs more, say what the increase buys in staff hours.
"What if we lose member data?" Answer with the mechanism, not reassurance. Where the export comes from, what format, who verifies the record counts match, and what the rollback is if the numbers do not reconcile. A board that hears "we export, we import, we verify counts against the old system before we switch off, and we keep the old account live for 30 days" stops worrying.
"How do we know this vendor will still be here?" This is where exit terms do the work. You cannot promise any vendor's longevity. You can show that the organization keeps a complete copy of its own data, in standard formats, at any time, without a fee. That converts an unanswerable question into a manageable risk, and it is the single strongest argument available to you.
Bring three things to the meeting
Beyond the deck.
The current contract, with the renewal date and notice period highlighted. Boards make faster decisions when a deadline is visible.
A written quote or published pricing for the proposal. Not a range. If a vendor will not give you a number in writing before the meeting, that is itself information for the board.
The exit terms of both platforms, side by side. What it costs to leave what you have, and what it costs to leave what you are proposing.
The thing most presentations get wrong
They lead with features.
A board does not care that the new platform has a better events module. They care about risk, cost, and whether the organization is more or less trapped afterwards. Features belong in slide one only as evidence of a problem you are solving, and nowhere else.
The proposals that get approved read as risk management. The ones that get deferred read as shopping.
If it helps to have a number that is not a quote, our pricing is published on the pricing page in Canadian dollars, and the exit terms are on the data ownership page. Both are things you can put on a slide without a sales call first.