Meet Ely and forget waiting lines

Clément Barbaza
10 min readJan 30, 2018

--

A report about the development of Ely, a French start-up (without VC funding) made to remove physical waiting lines.

In August 2015, Tomy Spagnoletti Duval and I decided to create a web application to manage waiting lines in a digital way and to remove physical waiting lines.

The initial idea comes from Tomy when he had a discussion with a restaurant owner in Toulouse, France 🇫🇷 regarding the management of clients who wait in his restaurant.

Waiting is lost time. We wanted to give back the waiting time to users who go to a physical store and make appointments, and make them free of their move.

So we decided to launch the project in our free time.

I will present you in this article the product development part of the project only (interface captures are in French, sorry for that).

Marketing website

Ely website.

The marketing website uses react.js coupled with vue.js and some angular.js, on a node.js stack with webpack, because, you know, technology matters. Yeah, you guess it right, I’m just trolling. Do you ask which brushes a painter used when you go to a museum? 🤔

It’s a simple one-page website, using Bootstrap 3 and jQuery, in a single PHP file made by Tomy, and it’s perfect for a marketing website.

And it works !

Management

We sometimes worked remotely, or sometimes in our personal houses. It depended on the tasks to do. Sometimes it’s easier to be in the same room for reflexion or taking decisions.

We used tools to manage the project:

  • Github: obviously, we used Github to store our code and git for versioning.
  • Trello/Jira: first, we used Trello to manage our tasks for product development, marketing, sales. But we reach the limits of Trello usage when we had lists (columns) containing more than 250 cards. After the launch of the version 1, we moved to Jira, configured by Tomy.
  • Evernote: we wrote our ideas, notes and information on shared notebooks.
  • Dropbox/Mega: we synced our folders and files for the project using Dropbox first, then we moved to Mega. We switched to Mega because we wanted to encrypt our files.
  • KeePassX: We used KeePassX to manage accounts and passwords of the project together and we synchronized them using Dropbox/Mega.

User and client definition

First, I want to define 2 terms I will use a lot next, users and clients:

  • I identify the user of the project as our client. It’s the person in charge of managing the entrance in the local business. It’s the person who uses the web application.
  • The client is the client of the user (so the client of our client). This person doesn’t use the web application. Everything is manager by the user.

Web Application

Ely is made with Laravel framework. It’s a web application that uses jQuery and Bootstrap 3for interface.

In August 2015, I first wanted to use vue.js, but at this time, it was the 0.74 version or something like that. We wanted reliable tools, and we had time constraints, so we chose to use jQuery, a library I know and in the market for a long time.

I made the web application, and Tomy created the interface wireframes, then customized the style.

Interface

Ely web application.

Of course, the interface of the web application is responsive to be accessible on smartphones, tablets and computers. We used Bootstrap 3 to help us to create the interface by customized it.

The main part of the interface is the keyboard, used for all the features of the project, and columns on the side (sidebars), to display clients information.

As you see, the interface is a lot inspired by Trello.

Keyboard

Left: waiting line keyboard. Right: booking keyboard.

The keyboard is the main part of the Ely interface.

The user enters the phone number of the client, and add the additionnal data depending of the feature.

The user always has to enter the phone number, and optionnaly can add the location, make the client VIP, and can enter personal information like his name, address…

On Ely, we use the phone number of the client as his unique identifier. But because a client can change his phone number, we make it possible to migrate a client account from an old phone number to a new phone number directly by our users.

The keyboard is dynamic and change regarding the active feature. For example, on the booking feature, the user can add the date and time.

Sidebars

Left: waiting line sidebar. Right: booking sidebar.

The user can personnalize the position of the sidebars.

There is a sidebar for each feature, one for the waiting line feature, one for the booking feature and one for the loyalty feature.

Weather

Weather interface.

We use some cool icons and The Weather Channel API to display the weather to our users, because it could be an interesting information. For example, the clients number of a restaurant on a period can change according to the weather (rain, snow…). But because the data of The Weather Channel are not completely reliable, the user can manually change and select the real weather (sunny, rain, snow…) for one hour.

Search

The user can search in the waiting line and booking tickets. When a ticket is done (validated, deleted or cancelled), the card is automatically archived. The user can access to all archived cards. He can search in archived cards too.

Features

Waiting line management

Left: Ticket on first state. Middle and right: Tickets on second state.

The user enters the number of the client on the keyboard who wants to reserve a place in the waiting line. The user can optionaly have more information about the client like his name, address, email… He can make the client VIP to quickly check if this client is important for the business.

Then, a ticket is created and the client is in the virtual waiting line (first state).

In this card, the client waiting time is now calculated and displayed for the user.
Of course, the user can always modify client information in the waiting line column.

When the user is ready to call his client, he just has to click on a button to warn the next client or a specific client. An SMS will be sent to warn the user on his phone. A timer is now launched. If the time is exceeded, a countdown in red color show how much the client is late (second state).

Now, the user just has to wait for his client to close the ticket and automatically archive it.

A closed ticket can have 3 states:

  1. Validated if the client came
  2. Cancelled if the client called to warn the user to cancel
  3. Abandoning if the client didn’t come.

Booking

A booking ticket on different states.

This feature is a classic booking feature using phone number as the identifier of the client.

Booking interface is very close to the waiting line interface, but we added the possibility to enter the date and the hour of booking with an integrated calendar on the keyboard.

For booking, compared with waiting line management, the user doesn’t have to warn the client. After the creation of the ticket (when the client booked a reservation), he just has to wait for his client to close the ticket and automatically archive it. States for closed tickets are the same as on waiting line management.

Loyalty

The goal of this feature is to replace the classic loyalty card by just a phone number. The phone number of the client is his identifier. Like that the client just has to tell his phone number instead searching for a card in his wallet and give it to the user.

The locality account, linked to the phone number of the client, is totally managed by the user. He can do what he wants with his loyalty advantage.

Marketing campaigns

The user has at least the phone number of the client, that’s why he can send marketing campaigns using SMS to increase his benefits.

The user can segment, filter and sort his clients using some parameters.

Statistics

Statistics interface.

This feature is just simple statistics about sent SMS. The user can track the SMS he sent to his clients.

Settings

Global settings interface.

Settings

  • Classic information settings. The user can manage his personal information like address, email, phone number, name…
  • Because we use Premium SMS, the clients of a user receive SMS with the name of the user as sender (on recent phones only). Having sender name automatically displayed when receiving an SMS is a personalization that increases the open rate. It’s possible for the user to personalize his name. That’s called a short name and has some constraints (max 11 characters, no space, no special chars…).
  • The classic feature for a user to change his password.
  • The user can activate/deactivate the weather. The weather could be useful for statistics.
  • The user can personalize the background of Ely app.

Objects

Objects are things a user can create/delete to quickly select them in tickets.
E.g. gluten free, smoker…

Places

The user can manage places to quickly insert place information in the ticket, and inside the SMS the client will receive.

SMS

We use a lot of SMS providers, like Twilio and Nexmo to send SMS, like that the client is sure to be warned.

We display the SMS state (sent, delivered…) to our users.

Of course, we respect the constraints due to the French law on marketing and transactional sms.

SMS settings interface.

Waiting line SMS

For the waiting line management, the user has the possibility to send 2 SMS.

Added in the waiting line notification

This message is sent when a user adds a client number in the waiting line and create a ticket.
The phone number to contact the user is automatically added in the SMS. A key is added in the SMS too. This key is the “password” of the client to manage his subscriptions in his manager (we will talk about that later).
The user can add a text to personalized his message.
The user can display a previsualisation of the SMS template that will be sent to his clients.
This message is optional.

Ready notification

This message is sent when the user wants to warn his client it’s his turn.
Like on waiting line notification, the phone number to contact the user and a key are automatically added in the SMS.
The user can add a text to personalized his message and can display a previsualisation of the SMS template that will be sent to his clients.
The user has to define the time he allows to his client to arrive. We calculate how far a user can move depending on the time defined to help our users.
This message is required.

Booking SMS

Booked notification

This message is sent when a user books a client reservation.
The phone number to contact the user and a key are automatically added in the SMS.
The user can add a text to personalized his message and can display a previsualisation of the SMS template that will be sent to his clients.
This message is optional.

Booking reminder

This message is sent when the user wants to remind his client he has an appointment soon.
The phone number to contact the user and a key are automatically added in the SMS.
The user can add a text to personalized his message and can display a previsualisation of the SMS template that will be sent to his clients.
The user has to define when he wants to remind his client (e.g. 30 minutes before, a day before…).
This message is required.

Sent messages

The user has a global view that displays a previsualisation of the SMS that will be sent to the client, and which SMS notification is activated or not.

An SMS sent by “PizzaBijou” user and received by a client.

Payment

We use Stripe for payment because it’s actually the best way to handle subscriptions.

Thanks to Stripe, the user can easily pause, resume or stop subscriptions directly in the web application.

Payment interface.

Subscriptions

The user has a monthly subscription he can stop, pause and resume when he wants.
Depends on his subscription, he can send more or less SMS per month.
He can change his plan whenever he wants (to downgrade or upgrade).

Invoices

The user can visualise and download his invoices.

SMS packs

If the user doesn’t have SMS anymore, the app will always work, except the fact he won’t be able to send SMS to his clients. But he can buy SMS to refill his SMS account.

Client website

Ely client website.

The client has a dedicated website he can use to manage his subscriptions in places he went.

The client can remove his phone number of the marketing list of the place he wants. He obviously can ask to remove his phone number directly to the user, but we added this feature to make the client remove his phone number alone to avoid spam or unsolicited messages from our users.

We garanty that the phone number is well removed because we manage ourselves the client list of our users.

We hate spam, even span indirectly from us. That’s why we want to do everything we can to avoid it.

Ely client interface.

This is how we made a marketing website and two web applications without VC funding on our personal time. Like I said before, it’s just the functional and technical part of the project. We did way more other things in various domains to make Ely happen!

This post was initially published on my blog clementbarbaza.com.

--

--