Join
AES
Join
AES
Contact
Us
Contact
Us
Before I go any further, you should know where this comes from. Association Executive Services has no commercial relationship with any IT vendor — no referral fees, no commissions, no preferred-supplier deals. We currently run about six different platforms across our secretariat clients, so what follows is not theory. It is drawn from what we are working with in live systems right now.
And here is the most useful thing two decades in this sector has taught me about judging a platform: the real measure is not the CEO, and it is not the Board. It is the person on your admin team who uses it every day. They are the ones who tell me what actually works and what quietly doesn’t. If you want to know whether a platform is any good, don’t ask the people who signed the contract. Ask the people who are using it every day.
Not because the technology is wrong. Because the scoping never happened. The Board approves a budget for a problem it doesn’t fully understand, a vendor is chosen on a third-party referral, and eighteen months later, the association has an expensive website that doesn’t talk to its membership database, costs twice the quoted figure to maintain, and belongs — legally — to someone else.
I’ve watched this pattern repeat for more than twenty years. Greg Hill and I unpacked it in a recent AES session, and the lessons are worth putting on the record.
In the 1990s, associations had a handful of providers to choose from and websites were little more than noticeboards. I still have screenshots of association websites from 2005 — walls of text, member login boxes bolted onto the side, banner ads from sponsors filling the homepage.
Compare those with the same organisations’ websites today: integrated membership portals, event registration, e-commerce, certification and training platforms, all sitting behind a clean front door. The website has gone from a brochure to the operational core of the association.
That shift is the point. When your website was a brochure, a bad decision cost you embarrassment. Now it costs you member renewals, event revenue, and staff time. The stakes have changed. Most procurement processes haven’t.
When association leaders come to us mid-project, the same issues surface every time:
Boards approve solutions they don’t understand. Directors of NFPs often can’t see how the proposed solution delivers the outcomes the association actually needs. They approve the spend anyway, because the alternative is admitting they don’t know. The fix is not for directors to learn to code. It is for the Board to insist on a requirements document it can understand, and to refuse to approve a budget until one exists.
No single solution meets the total need. Associations run membership, events, education, advocacy, and publishing. It is unlikely one platform will do all of it well. Integration between systems — not any single system — is where projects succeed or fail.
Third-party referrals are not due diligence. “Another association uses them” is the most common reason a vendor gets shortlisted. It is also the worst. Their requirements are not your requirements, their membership model is not yours, and the version they bought two years ago is not the one you’ll buy.
The real costs are not in the quote. Build cost is the visible figure. Licensing, maintenance, future updates, technical support, customisation, and scaling are where the money actually goes. Ask for the yearly and monthly figures, in writing, before you compare anything.
Staff resources, cyber security, and support are afterthoughts. Until they aren’t.
Here is where most projects come apart. The Board signs off on a website. What the association actually needs is for that website to communicate with its membership database — so a member who renews online is marked as financial, can register for an event at the member rate, and can access the resources their category entitles them to, without a staff member rekeying anything.
When that link works, the website is an operational asset. When it doesn’t — and it frequently doesn’t, because the website vendor and the database provider are two different companies with no contract between them — you have bought a very expensive front door with a filing cabinet behind it that someone has to update by hand.
Ask the question early and ask it bluntly: which system is the source of truth for member data, and exactly how does the website read from and write to it? If the vendor’s answer is vague, the integration is your risk, not theirs. Get the answer from the requirements document and have it tested before sign-off.
And understand that integration is almost never a one-off cost. Every platform you connect — payment gateway, membership CRM, accounting system, email marketing, learning management — can carry its own connector licence, API charges, or middleware, and most of it recurs every year. The website quote rarely includes any of it. Price each connection annually, and add it to the comparison before you commit. The integrations are usually where the ongoing cost lives.
The quote you compare vendors on is the tip. Underneath it sits the cost that actually lands on next year’s budget and the year after that: annual licensing per module, hosting, security patching, the “minor” change requests that each carry a day rate, the version upgrade in year three that turns out not to be included, and the integration work nobody scoped.
I’ve seen associations sign on a build figure that looked competitive and discover, eighteen months in, that the true annual cost of ownership had become a recurring line item larger than the original build. None of it was hidden. None of it was asked for either.
Before you compare a single vendor against another, get the total cost of ownership over a realistic period — three to five years — in writing: build, licensing, hosting, support, expected change requests, and upgrades. The cheapest build is regularly the most expensive website.
Find out what support means before you sign, because the gap between what associations assume they’re getting and what they get is wide.
Some vendors offer genuine 24-hour cover. Others offer support that is ad hoc, slow, and routed through a ticket queue that treats your down member portal as a low priority. When event registration breaks at 4pm on the Friday before your conference, that difference stops being academic. Get the support model in writing: hours of cover, guaranteed response times, how an urgent issue is escalated, and what it costs. “We’ll look after you” is not a support agreement.
Ask where the support team actually sits, because plenty of it now runs from overseas. That can work perfectly well — but it can also mean that when your system falls over at 9am Melbourne time, the people who fix it are asleep on the other side of the world. You log the ticket, and nothing happens for hours because the office that handles it doesn’t open until your day is finished. For a website that drives member renewals and event registration, a support team in the wrong time zone is not a discount — it is a liability you discover at the worst possible moment. Ask which hours the team covers in your time zone, not theirs, and get it in writing.
Training is the companion problem. Vendors will point you to a library of training videos, and they have their place — until the moment you have a specific question the library does not answer. Generic videos teach the generic product. They do not teach your configuration, your member categories, or the workflow your staff run, and a frustrated staff member hunting through twenty videos for one answer is a hidden cost you are paying in time. Budget for proper handover training built around your setup, and make it a named deliverable in the contract — not a playlist you are left to interpret on your own.
Before anything is signed, satisfy yourself on six things: that the contract defines the full scope of work with deliverables, timelines, and milestones; that the payment schedule is clear, including upfront fees and final payment terms; that you retain ownership of the website’s design, code, and content; that termination conditions and penalties are spelled out; that the warranty period and defect coverage are adequate; and that the vendor’s liability isn’t limited to the point of being meaningless.
The ownership question alone has trapped more associations than I can count, so it is worth being precise about what it means. If the vendor owns the code, you do not have a website — you have a subscription, and the renewal price is whatever they decide it is once they know how dependent you are. The associations that get caught are the ones that never asked three questions:
• Who owns the code, the design, and the content? It should be you. Get it in writing.
• If we leave, what do we walk away with? You want your data in a usable format and the ability to host elsewhere. If leaving means starting from scratch, you were never the owner.
• Where does the site live, and can we move it? Hosting lock-in is ownership lock-in by another name.
If the vendor resists any of these, that resistance is the answer. Walk while you still can.
The line I used to put last — that cybersecurity and data are afterthoughts until they aren’t — has earned its own section.
Your website now holds members' names, contact details, payment information, qualifications, and, in some sectors, health or professional conduct records. That is exactly the kind of personal information the Board is legally responsible for protecting. A breach is not an IT incident that the office quietly cleans up. It is a notifiable event, a reputational hit with your members, and a question the Board will be asked to answer.
So treat it as a governance matter at the procurement stage, not a technical detail after go-live. Ask where member data is stored and under whose control, what the vendor’s breach-notification obligations to you are, who is responsible for security patching and how quickly, and whether the arrangement meets your privacy obligations. If the Board cannot get clear answers to those questions before signing, it is approving a risk it has not assessed.
And do not accept “in the cloud” as an answer. The cloud is just someone else’s computer, and it sits in a building, in a country, under that country’s laws. You need to know which one. Member data held offshore can fall under another jurisdiction’s rules — rules that may sit outside the protections your members expect, and that may not square with your obligations under Australian or New Zealand privacy law. If the vendor cannot tell you which country your data physically lives in, who can reach it, and what happens to it if they go out of business or you walk away, the Board does not control its own member data. Get the storage location named in writing, and confirm it meets your privacy obligations before a single record is migrated.
The single biggest improvement any association can make is to do the thinking before the market does it for you. Five steps:
1. Define your objectives. Clarify goals, identify the target audience, and set key performance indicators. If you can’t say what success looks like, no vendor can build it.
2. Assess your current website. Gather user feedback. Identify what works and what must go. Measure the performance you have before specifying the performance you want.
3. Develop a full requirements list. Functional and non-functional. What the site must do, and how it must perform — speed, security, accessibility, integration.
4. Do the market research. Analyse comparable associations, look at current trends, and seek inspiration before you write the brief.
5. Prepare a requirements document. One document that summarises objectives, requirements, and scope. This becomes the basis of every vendor conversation and, later, the contract.
Walk into vendor meetings with this document and you control the conversation. Walk in without it, and the vendor’s product roadmap becomes your requirements list.
Four roles need to be filled and named before the build starts: a project manager who coordinates teams and keeps the timeline honest; the website company, responsible for the build and the technical functionality; your own organisation, which owns the content — text, images, video; and system testers, who hunt for bugs and usability problems across devices and browsers.
Then test properly before sign-off: every feature, ease of use for your actual member audience, performance across browsers and devices, speed and responsiveness. Establish the sign-off criteria in advance, in writing. Sign-off should confirm that requirements were met — not that everyone is tired and wants the project finished.
A website project is a governance decision with a technology component, not the other way round. The associations that get it right are the ones that invest in discovery, requirements, and contract scrutiny before a single pixel is designed. The ones that get it wrong skip straight to the demo, fall for the referral, and find out about ownership, integration, and total cost when it is too late to do anything but pay.
If your association is reviewing its website or weighing up a move to a new platform, start with the requirements document. Contact us at Association Executive Services for more information
A renewal invoice is not a request for last year's money. It is a request to pay for next year's benefits. The moment a member — individual or corporate — opens that invoice, they make a decision: renew, or walk.
If your association is thinking about a rebrand because the colours look dated or a Board member doesn't like the typeface, stop. That's not the question worth asking. The real question is harder: does your organisation still represent the sector it claims to lead?
A Returning Officer is an independent individual appointed to oversee the election of Board Directors and ensure the process is conducted fairly, transparently and in accordance with the association's Constitution, By-Laws and any Board-approved election procedures.
How we help membership based, not-for-profit associations now and into the future.
