What is a loyalty program RFP?
A loyalty program RFP, or request for proposal, is a brief that asks vendors to explain how they would deliver your program, what it would cost and which requirements they can support. It should make proposals comparable, including the difference between existing features, custom development and work your own team must do.
For Shopify merchants, the brief should cover the membership model, benefits, customer accounts, integrations, migration, online and in-store journeys, launch checks and ongoing ownership. Describe the outcome you need before prescribing a technical solution.
A formal RFP is useful when several teams or vendors are involved. If your program fits standard app features, a short checklist and a trial may be enough. A larger member count alone does not make custom development necessary.
Download the editable requirements worksheet
The free CSV contains 24 starter requirements with space for your priority, acceptance test, vendor response, delivery method, evidence, costs, owner and decision. Open it in Excel or import it into Google Sheets. No email address is required.
Download the RFP worksheet (CSV)
Keep one master requirements list and make a copy for each vendor. Add your project summary separately, edit the suggested tests to match your program and remove rows you do not need. Blank vendor answers are intentional: the worksheet does not claim that Memberply or another vendor supports every requirement.
- Priority: use Must have, Should have, Optional or Not applicable.
- Delivery method: ask for Standard, Configuration, Custom, Third party, Roadmap or Unsupported.
- Evidence: request a relevant demonstration, documentation or an agreed acceptance test.
- Decision: record Accepted, Needs clarification or Rejected, with an owner for follow-up.
Write a one-page project summary first
Give every vendor the same starting information. This helps avoid proposals based on different assumptions.
| Include | What to write |
|---|---|
| Business goal | The behavior you want to change, such as a second purchase or continued paid membership. Define how you will measure it. |
| Customers and offer | Who can join, free or paid membership, tier rules, benefits, purchase frequency and exclusions. |
| Store setup | Shopify plan, store count, customer account experience, markets, currencies and participating POS locations. |
| Existing systems | Current membership platform, payment provider, CRM, email tools and internal systems that need data. |
| Project boundaries | What must work at launch, what can follow later, who approves decisions and what is out of scope. |
| Budget and timing | Your budget range, desired launch window, fixed dependencies and availability for testing. Ask vendors to state assumptions. |
Ask questions that reveal the implementation scope
| Area | Ask the vendor | Evidence to request |
|---|---|---|
| Benefits and eligibility | Which earning, redemption, expiry, cancellation and refund rules are standard? | Demonstrate one eligible member and one ineligible member using your proposed offer. |
| Customer account design | Which parts of the proposed experience fit Shopify’s supported account components? | A feasible layout and a list of design differences, account requirements and custom work. |
| Integrations | What data moves, in which direction, when and through which supported interface? | A field map, event list, failure/retry behavior and a named owner for each system. |
| Migration | How will member identity, tier access, balances and recurring payments be handled separately? | A pilot import and reconciliation plan, plus payment-provider dependencies and member actions. |
| POS and channels | Which benefits can be earned or redeemed in each channel? | A register demonstration using the correct customer, including reward timing and exceptions. |
| Data and security review | What access is required and which retention, export, deletion and security documents are available? | Current documentation for your team’s review, rather than unsupported certification claims. |
| Delivery and ownership | Who configures, builds, tests, approves and maintains each component? | Milestones, deliverables, acceptance criteria and responsibilities for both teams. |
| Costs and support | Which fees are recurring, usage-based, one-time or optional? | Itemized proposal, exclusions, support coverage and written terms for any service commitments. |
Shopify customer account extensions use supported targets, APIs and components. An unrestricted website design is not automatically a feasible account design. Ask vendors to review the actual layouts against Shopify’s customer account extension model.
Saved payment methods and subscription contracts need their own assessment. A member CSV import does not establish that recurring payments can move. Review the proposed route against Shopify’s payment migration guidance.
Replace vague requirements with testable ones
These are illustrative requirements to adapt, not promises that any vendor already supports the requested workflow.
| Vague request | More useful requirement | Acceptance check |
|---|---|---|
| Integrates with our CRM | Send the agreed membership status and tier fields to the named CRM when membership changes. Specify direction, timing and record matching. | Change a test member’s tier and verify the mapped record. Simulate a failed delivery and check the agreed recovery process. |
| Move all our members | Map customer identities and tiers, reconcile balances separately and agree a plan for recurring billing. | Compare pilot records against the source and confirm no duplicate credit or overlapping billing is introduced. |
| Custom member portal | List the member actions and approved design elements for the chosen Shopify account experience. | A member completes the required actions on mobile; an ineligible customer cannot access the protected benefit. |
| Works in store | List which benefits staff must recognize, apply or redeem in Shopify POS, and when rewards become available. | Run a test sale, review the discount and resulting credit, then test the agreed return scenario. |
Compare evidence before assigning a score
Review must-have requirements first. A strong total score should not hide an unsupported essential workflow. Resolve blockers and uncertain answers before selecting a preferred proposal.
For the remaining requirements, a simple manual rubric can be useful: 0 means unsupported or no evidence, 1 means a partial fit with unresolved work, and 2 means the requirement has been demonstrated or has a clear agreed delivery and acceptance plan. Keep the delivery method visible: a custom project with an accepted plan is still different from a feature available today.
Set priorities before reviewing vendor answers. Treat a roadmap item as a dependency until its delivery, timing and responsibilities are agreed. Record why you accepted a tradeoff, not just the score.
The worksheet leaves assessment fields editable and does not calculate a winner. Your team should review commercial terms, implementation risk and required evidence alongside feature fit.
Compare the full cost and support commitment
Ask every vendor to quote the same agreed scope and time period. Separate app fees, setup, custom development, third-party services, migration, ongoing support and your own team’s work. Record the currency and whether taxes are included.
For usage-based pricing, request estimates using the same member, order and message assumptions. Clarify what happens when those assumptions change. Keep reward costs and shipping subsidies visible in the business budget even if they are not part of the software quote.
Ask who maintains custom code, handles platform changes and investigates failures between systems. If response times or availability are important, request written commitments and exclusions. Do not infer an SLA from the word Enterprise.
Use the Shopify loyalty program cost guide to separate operating costs from the implementation proposal.
Use the RFP to agree a launch plan
- Agree the brief. Have marketing, store operations and technical owners review the same requirements.
- Request comparable answers. Give vendors the same worksheet, assumptions and response deadline.
- Resolve gaps. Ask for evidence and identify unsupported requirements, custom scope and third-party dependencies.
- Run a focused demonstration or pilot. Use representative journeys and data approved for testing.
- Confirm the proposal. Agree deliverables, costs, acceptance tests, responsibilities and support terms.
- Approve the rollout. Name the launch decision-maker and the process for pausing rollout when a critical test fails.
Measure a pilot against a realistic baseline. Separate new members from established repeat buyers, and match your review period to the normal purchase cycle. A proposal promising higher member spend should explain how it distinguishes existing loyal customers from additional behavior caused by the program.
How Memberply fits into your evaluation
Growth includes Memberply’s standard features to launch and grow your membership program. Enterprise is for separately scoped custom integrations, development and implementation. You can use this checklist to establish whether your requirements need custom work at all.
Memberply has standard integrations including Klaviyo, Omnisend and outbound membership webhooks. A request for a different system or a two-way data flow needs review of the available interfaces, permissions and responsibilities. Standard integration availability does not mean every field or workflow is already supported.
For a custom project, share your store URL, goals, required member journeys and completed requirements list through the Enterprise enquiry page. Start with field descriptions and redacted examples rather than live customer exports. We can review the standard options and scope the gaps.
Use the Shopify Plus guide, integrations guide, migration checklist and omnichannel guide to prepare the relevant parts of your brief.
Loyalty program RFP FAQs
What should a Shopify loyalty program RFP include?
Include your goals, membership model, benefits, customer account experience, integrations, migration, POS needs, acceptance tests, costs, ownership and support expectations. Ask vendors to distinguish standard features from custom work.
Is the loyalty RFP worksheet free?
Yes. Download the editable CSV without providing an email address. Open it in Excel or import it into Google Sheets, then adapt the requirements for your project.
Do I need an RFP to launch a membership program?
Not always. A checklist and a trial may be enough for a program using standard features. A formal RFP is useful when multiple vendors, teams or custom requirements need comparison.
Does the worksheet list features Memberply guarantees?
No. It is a buyer’s requirements template. Vendor answers are blank so each provider can confirm scope, limitations, evidence and costs.
How should I compare loyalty vendor proposals?
Resolve must-have requirements first, then compare evidence, delivery method, costs, dependencies and ongoing responsibilities. Do not let a total score hide an unsupported essential workflow.
Can importing members transfer their payments too?
Member import and payment migration are separate. Review the gateway, subscription setup, member actions and billing transition before assuming recurring payments can move.
Do I need Enterprise for all of Memberply’s features?
No. Growth includes the standard features to launch and grow a membership program. Enterprise is for custom development, integrations and implementation agreed for your project.