WHY YOUR LAST RFP DIDN'T WORK
Your board asked for a website redesign. Your executive director asked your administrative staff to "put together an RFP." Three weeks later, you had a 47-page document filled with checkbox requirements, features lists from three different template platforms, and three years of accumulated frustration about why the current site doesn't work.
You sent it to seven vendors. Three said "yes, we can do that." Two sent back quotes that made no sense. One vendor took six months to respond because they were reading the same 47 pages you were still confused about. One didn't respond at all.
The problem isn't your vendors. It's that your RFP tried to be exhaustive instead of clear. Vendors can't give you accurate pricing on requirements they don't understand. You can't compare proposals that are all answering different questions. And all that effort—the three weeks of work—produced nothing but confusion.
What an Association RFP Actually Needs
A good RFP for a trade association website has five sections. Not 47 pages. Five clear sections that tell a vendor: here's what we do, here's what's broken, here's what success looks like, here's our timeline, here's how we'll decide.
SECTION 1: YOUR ORGANIZATION CONTEXT
Start here: two paragraphs that answer these questions directly.
Two paragraphs. What does your association do? How many members? What's your current technology stack? (iMIS? Fonteva? Something else?) When was your last redesign? Why are you redesigning now?
Example (real association, anonymized): "The National Association of Industrial Inspectors represents 4,200 active members across three tiers: certified inspectors, corporate members, and affiliate members. We run iMIS 10.2 for member management. Our current website was built on WordPress in 2018 and hasn't been updated significantly since then. We're redesigning because member feedback points to a frustrating user experience, our event registration system doesn't talk to iMIS, and our staff spends six hours a week manually syncing member data."
That's context. That's specific. A vendor reading that knows what they're walking into.
SECTION 2: CURRENT SYSTEM CONSTRAINTS AND FAILURES
Here's where specificity saves your project: describe problems, not features.
Don't list every feature you want. List what's broken and why it matters.
Examples: "Member login doesn't persist across event registration—members log in on the main site, then have to log in again to register for events, creating support tickets." "Our AMS is iMIS. Event registrations don't sync to member records automatically. Staff manually uploads attendance data weekly." "Our email platform (Constant Contact) doesn't sync with iMIS. Member list updates require a 24-hour manual export-and-reimport cycle."
Quantify impact: "This costs us 6 hours per week in staff time. It also creates data errors that appear in renewal workflows."
Vendors read this and immediately understand the scope of integration work. They can price it. They can tell you whether it's possible with standard tools or if it requires custom development.
SECTION 3: MUST-HAVE VS. NICE-TO-HAVE
Separate these clearly. Not everything is a must-have.
Must-Have Examples:
- Single sign-on for members (member logs in once, stays logged in across the site and member portal)
- AMS integration: member contact changes in iMIS appear on the website within 24 hours
- Event registration syncs to iMIS member records automatically
- Member portal showing membership tier, renewal date, event history
- Mobile-responsive design
Nice-to-Have Examples:
- Member-to-member messaging
- Discussion forums
- Certification tracking dashboard
- Integration with email platform (might happen in phase two)
This distinction is where vendors can give you fixed pricing vs. time-and-materials pricing. Must-haves are scope. Nice-to-haves can be phased or descoped if budget requires it.
SECTION 4: TIMELINE AND BUDGET REALITIES
Be specific about your constraints.
When do you actually need this done? (Not "ASAP." Specific date.)
What's your budget range? (Don't be shy. Write: "Budget range: $45,000 to $75,000 for design and development, excluding AMS integration. AMS integration budget TBD based on scope.")
Can that budget flex? (Some associations have: "$50,000 fixed budget. If AMS integration exceeds this, we'll descope community features to phase two.")
How many review cycles do you anticipate? (Design rounds, content revisions, testing. Be realistic.)
Vendors need these answers to give you realistic proposals. A vendor who quotes $35,000 when you say $50,000-$75,000 is either cutting corners or doesn't understand your scope. A vendor who quotes $120,000 might be right, but if that's outside your budget, say so upfront so they can suggest a phased approach.
SECTION 5: HOW YOU'LL EVALUATE PROPOSALS
This matters more than you think. Vendors will pitch to what they think you're evaluating on.
If you only care about price, vendors will race to the bottom. Their proposals will be thin. You'll get cheap. You won't get good.
Be explicit: "We'll evaluate proposals on:
- Understanding of association operations and AMS integration (30%),.
- Proposed timeline and clarity of deliverables (20%),.
- Team experience with association websites (20%),.
- Price (20%),.
- References from associations with similar complexity (10%).".
Now vendors know what matters. They invest time understanding your actual needs, not guessing at your evaluation criteria.
THE AMS INTEGRATION SECTION (CRITICAL)
If you're running an AMS, your RFP needs a dedicated section on integration. This is where most proposals go sideways.
Specify your AMS: "We run iMIS 10.2 with the following modules: Member Management, Event Management, Community (forums), and Finance."
Specify the integrations you need:
- Member authentication: website login pulls from iMIS member database
- Member data sync: changes in iMIS (email, phone, address, tier changes) appear on website
- Event registration: registration through website syncs to iMIS event records
- Member directory: public or tier-restricted directory pulls from iMIS
Then ask the vendor directly: "Have you integrated with iMIS before? What was the approach? Did you build custom APIs or use iMIS native tools? What was the timeline? What challenges did you encounter?"
That answer tells you whether they've actually done this or whether they're about to learn on your project.
AMS and CRM integration is not standardized. Different platforms have different capabilities, different API maturity, different documentation quality. The vendor's honest answer to this question is worth gold.
RFP RED FLAGS
Some vendor responses should set off alarms.
Red Flag 1: "We'll use the iMIS REST APIs and connect directly to your database." (You don't want vendors connecting directly to your member database. That's a security and compliance issue.)
Red Flag 2: "We've never integrated with iMIS before, but it's just a matter of reading documentation and building API calls." (It's not. iMIS has quirks, and they matter.)
Red Flag 3: "AMS integration will be 40 hours of work and $8,000." (For actual iMIS integration? Probably underestimated by 2-3x.)
Red Flag 4: Proposal is vague on timeline. "Development will take approximately 3-4 months." (When does it actually start? When is testing? When is launch? Vague timelines slip.)
Red Flag 5: Proposal doesn't separate design, development, AMS integration, and content migration. (These should be clearly distinguished because they're different skill sets and timeline drivers.)
AFTER YOU SEND THE RFP
Good vendors will ask follow-up questions. They'll want to talk through your workflows, understand your event cycle, see your current site in action.
Expect vendor conversations (30 to 45 minutes each) before they propose. If a vendor sends a proposal back within 48 hours without conversation, that's a bad sign. They're not reading your RFP carefully.