16 Questions & Answers Before Launching a Loyalty Program

In short, you need to have something put together and prepared that requires strategic planning. Here are a couple of boxes you should check:

• Define the member journey, including rewards and earning structures, like tiers or points
• Prepare a business model and budget plan
• Work on the post-launch marketing or advertisement strategy
• Select a loyalty technology vendor (or at least, prepare an RFP)
• Understand the edge cases and potential pitfalls
• Clean your database to migrate the customer data
• Have buy-in for all of this from other departments, like finance, CRM or IT

Two words: rigid architecture. If the backbone of the loyalty software you are using is insufficient, it’s like trying to use a dial-up internet. This leads to spending time and resources on developing workarounds for the simplest solutions, rather than launching new rewards and creatively iterating your program. Alternatively, your loyalty strategy might also spin out of control if you have to do post-launch damage control due to inconsistent logic or forget to test unique edge cases, like how returning a product affects tier progression. 

The best time to start thinking about the details is between the scoping and implementation phases. Luckily, you don’t need to do this on your own: Antavo offers products that help you flesh out the loyalty logic. For example, our Planner generates structured member journeys based on your concept documents or even a recorded idea pitch. Then you can use this blueprint as the layout for the implementation. Remember, planning takes time, but every solid decision you make will make the implementation phase quicker. 

To give you a direct answer: when you have identified the milestones for technical deliverables, and know how long each step would take. In general, it’s important to understand that your plan doesn’t need to cover every aspect from start to finish to begin implementation, as some details will be finalized mid-work. The reason you need some kind of plan is to get your priorities in order, know how long development resources need to be booked, and identify where you need buffers to align the various martech software. 

That depends on your program’s scope and complexity. The more unique your customer experience should be, the more groundwork is needed. First, you need to know what experience the customers will be, what channels you’d like to interact with them (mobile, website, in-store), what information they need to provide, etc. The rule of thumb is to try and think of as many touchpoints as you can (after all, you can always make alterations later on).  

There’s no definitive checklist, as all projects have their unique bells and whistles, but here are the most common items that might get overlooked:

• Edge cases, like how the different rules will impact each other
• Costs and margins for how to ensure that the program doesn’t lose money
• Fraud cases or exploits that come from uncovered loopholes and contradicting rules
• A USP or special experience that makes the loyalty program stand out. A well-designed gamification feature, for example, can generate a lot of word-of-mouth. 

1. The customer takes an action (e.g. purchase, signup, check-in) that triggers an event within the system
2. The event is received and customer eligibility is validated
3. The loyalty platform applies the corresponding rules: assigns or burns points, and distributes rewards
4. There’s some circulation within the system. For example, if the customer is eligible for points, it might trigger a tier level up, or if the system includes personalization elements, it needs to decide whether to grant a coupon or a special perk
5. The changes then need to be processed and recorded in the CRM database
6. The changes were then synced and propagated through the frontend interfaces. For example, the member’s profile should now show the updated point balance.

Demos are always a slice of the pie, not the whole thing. Potential issues can be data issues from migration, or the program wasn’t designed technically in a way to cover special use cases and a workaround had to be applied. A lack of proper end-to-end testing might also alter how the end product behaves. 

Successful execution and rule running depend heavily on your data setup or data strategy. Usually its not a problem if your database is not perfect when the project starts. You just need to know what data you have available and where to find it, or how it is communicated across systems (e.g., from the CDP to the loyalty platform). Try to simplify and avoid highly complex solutions that could undermine future extension potentials. Also, try to be consistent: if you handle one data flow in a certain way, implement it consistently across all events.

• Data patches: you need to make sure your loyalty platform is synced with other platforms to get information, such as retail transactions, across. Without patching these holes, customer interactions won’t be properly rewarded.
• Data propagation might also go awry: even if the proper point balance is calculated in the loyalty platform, the frontend fails to update on the customer profile. 
• In short, the data won’t be consistent across your systems, which can lead to missed or incorrect communication, strange customer experience, all of which would require lots of manual scripting work to fix.

Before pushing the big red launch button, be sure to cover the most critical edge cases:

• Can your current ruleset cause financial issues? For example, if someone receives a tier level-up reward, but then gets downgraded, do they receive another tier-up benefit for reaching the same level for a second time?
• Can it cause customer frustration or misunderstanding? Not being clear about what happens after a product return (resulting in a revoked reward for a returned purchase) is not a great experience. 

• Edge cases that impact your margin or cause customer frustration
• UX design
• Omnichannel communication (how to stay in touch and connect with members when they are on the go, or in the store)
• Reporting and ROI (you need to clearly define your KPIs and benchmarks while designing the program, and think about how to measure them after the launch)
• End-to-end testing, to ensure that the customer experience is great

The most important thing is to get your team ready: each member should be aligned with their roles and responsibilities. This is especially true for your customer support team members, who should be prepared to address or resolve any complaint. Simultaneously, be sure to wrap up the launch strategy, especially if you have planned a special reward campaign around it. Lastly, catch up on the documentation. It’s easy to forget this during the pre-launch chaos, but trust us, you want your details in order once you get to the first phase of iterating on the loyalty program. 

Most commonly, you’ll need the terms and conditions in place when members are frustrated about an expiration rule or their experience has been altered (e.g. a reward has been revoked) and you need to point out why the decision was rightful. You will also need it for audit or data protection-related screenings. It goes without saying that you need to have the terms and conditions finalized at the moment of launch. 

• They have experience. If it’s not their first rodeo, your team members have first-hand knowledge of what to pay attention to and how to avoid roadblocks. They also have the documentation for both the technology and tech scoping, which significantly speeds things up
• All of their use cases are flexibly supported by their chosen loyalty platform. For them, it paid off to lay the ground work is before planning to ensure that only technically deliverable use cases are included
• They secured buy-in from the finance team and higher-ups, so they didn’t order a re-evaluation during implementation due to unforeseen risks
• Cross-department teams were properly organized, and the data was prepared in advance. Therefore, the implementation happened without technical difficulties or last-minute scope changes
• They did proper end-to-end testing. 

Again, this depends on your unique business case. But here are the usual suspects.

• Missing experience
• Disorganized team
• Missing functional requirements
• No deadlines (or unrealistic ones)
• Lack of proper technical scoping