The history of ‘UNLCKD’, our loyalty scheme
This post is about the history of UNLCKD – why and how it came to be, the challenges we’ve faced and our decision to scrap the first version that was built in favour of buying a solution.
The business challenge
Back in August 2018, the business realised it had gaps in how much it knew and understood about our customers. A significant number of people were signed up to the mailing list and our open rates were in line with industry standards – in other words, our customers were pretty engaged. However, the business realised that if we knew more about our customers, we could make better-informed decisions both for them and the business.
The business had hunches about the answers to the questions it had about customers, but it needed data to build a more accurate picture of their needs, desires and demographics.
A quick and easy solution?
To bridge the gap in our knowledge, Footasylum launched a loyalty scheme – something where we could thank returning customers with points that could be converted to money off future purchases, plus some money-can’t-buy benefits. The assumption – as with most similar schemes – was that these rewards would encourage customers to tell us about themselves so we could tailor the Footasylum experience to them.
Progress started on UNLCKD and August 2018. There was a h-u-g-e marketing plan in place which meant that the launch date was fixed and the app came into existence through waterfall delivery. When it launched, customers could sign up for an account, see their points, redeem vouchers and enter competitions.
Not quite on track
Unfortunately, take-up was slower than the business had anticipated. Training was offered to colleagues in stores to help them remember to prompt customers to download the Footasylum app in stores – which often had limited wifi coverage – and then use UNLCKD from there.
Soon enough, flaws in several of the user journeys began to show.
How much of our original data problem were we solving?
The scheme was helping the business understand customers online and in-store shopping habits, true. But there were questions around how reliable it was. Bottom line: what was being collected wasn’t robust enough for us to go on to deduce meaningful insights in customer behaviour and consequently make decisions that were informed by it.
Retrospectively service mapping to understand the problems
Digital teams use service maps right from the alpha stage of a project – it’s best practice. Service maps depict each interaction a user has with a service both on and offline – from a customer’s first step when they google ‘Footasylum loyalty scheme’ (or similar), to when they sign up, all the way through to when a customer redeems their points against a purchase. They also map out if there are any loop-backs, for example, when a user forgets their password and resets it.
There are many benefits to service mapping but one is to identify where the problem areas are. That’s exactly what we needed.
So, instead of service mapping alongside the development of UNLCKD, we did it retrospectively in September 2019. By this time, we’d built a team who were more familiar with practices that are used in Digital disciplines – service mapping is an example. Here's a photo of some of us on a Zoom call.
The courage and integrity to make changes
The mapping showed the disparity between what the original purpose of the loyalty scheme was and what it could actually do. UNLCKD over-promised and under-delivered. We took our findings to the senior team. Since then, we’ve made huge changes to the tech, the product and the design. We’ve scrapped much of what we had before. And we’re still working through many of the remaining problems.
Our aim since has been to simplify everything and make it work.
Decisions, decisions: to buy or to build
When we inherited the product, we were dealing with a lot of legacy code and technical debt. It had been built in an uncollaborative, waterfall way and a complete reset was needed. We had to make a decision about whether we should build something else ourselves, or, whether there was something already on the market we could buy and integrate.
We looked for a partner who:
- offers ongoing collaboration
- mirrors our ways of working
- upholds robust data standards (cleansing, processes and governance)
- offers good value for money
- is API-driven for successful integration
- offers a customisable product that allows flexibility to make changes
- openly shares comprehensive technical documentation
- offers support post-launch as well as during integration
The decision to buy was made collaboratively. From our initial research we knew there were partners out there that could meet our needs so we put forward our recommendation to buy to the senior team. They approved and the procurement process went ahead.
Our chosen supplier Talon.One provides a promotions engine which creates rules, manages account creation and loyalty point allocation.
More recent work
For the last 5 months, we’ve been mapping out the service so we can integrate with Talon.One; building APIs, and creating designs for new user journeys. We already have a much more usable, robust product.
We’re currently facing the challenge of communicating well with our stakeholders. It’s essential we present and explain research and design to them often so that as the subject matter experts, they can raise concerns immediately and help shape the work. We’ve been using Basecamp 6-week cycles and asynchronous communication methods and found them really helpful – we’ll talk about this in a post soon.
Chloe Barton Product manager