Do you like standing in queues? I bet you don’t. Especially if we are talking about queues in which customers have to stay not for an hour or two, but for weeks, sometimes even months. The Picnic app has its own sort of queue. We call it the waitlist — a white screen with a big red number.

What we had

On one hand, the waitlist helps us to provide the best possible service to our customers: it allows us to align the number of people that have access to our service to the capacity that we have available. On the other, we know that waiting itself is still a very frustrating experience. After people invest effort and time in our service, by downloading the app and walking through our registration process, they end up on a static screen that doesn’t provide them with a welcoming feeling and doesn’t give them any sense of value. By this time, we already had a “wait softener” program running in the background. The program exists to improve customers’ waiting experience by gifting some of our products over time. Unfortunately, customers only learn about this post factum, without the ability to select gifts themselves.

Our goal was to make the first steps more appreciative by presenting users with virtual value — the first Wait-softener, and giving them the ability to select it right when they finish their registration. Over time people on the waitlist are going to experience multiple positive interactions before even shopping in the app by celebrating with us and receiving gifts all the way during their waiting.

What we built

Besides business requirements, we had to consider some functional needs:

1. At specific times, code blocks should run to emit events on the state of the journey that our customers are in. The intervals in which this code runs should be easy to change for developers.
2. Business analysts and operators should be able to change configurations, such as gifts themselves and time intervals when we propose the gift to customers.
3. The system should be scalable.
4. We want to reuse the system skeleton for future projects.

To fulfill all the requirements, we had to come up with a solution that combines all the best from existing on our orbit systems and technologies. This turned out to be a combination of 4 independent services, communicating with each other via REST and RMQ events:

1. Java core, that collects, processes, and emits the data about users and their gifts, selected or not.
2. Python cron job, which runs regularly to go through our customers base and triggers the following processes, such as gifts creation and sending personalized messages about the waitlist journey.
3. Rule Engine, which is a homebrew system, that allows people without a strong technical background to create and update business rules and related configurations. The rules are getting run as a result of associated RMQ events handling.
4. Selligent: a third-party system responsible for all the communication, starting from channel selection and finishing with localization.

As a cherry on the top, we used React Native for the frontend, to make the user experience extra smooth:

What we achieved

At the moment we can assess the results in only a small timespan, but the numbers we see are already incredible. For those couple of weeks, the project is live, we are having a huge uplift in first order and app open conversion.

But with this project we got something else, namely the powerful combination of technologies that allows us to make new features even more powerful, having the ability to schedule new logic to execute at a low cost.

Perhaps we didn’t help our customers fall in love with being in a queue, but at least we made it more bearable. After all, in online grocery shopping time is of the essence, so more amazing projects based on the new system are coming.

Want to help us work on awesome projects like this? Check out our careers site here!