Table for More

Most people don't eat out alone, yet EatClub only ever met the person who paid. We built deal sharing so the host could bring the whole table along, and 61% of guests in its first week were new to EatClub.

Company
EatClub
Role
Product Designer
Timeframe
9 months
Four friends laughing around a restaurant table with burgers, fries and drinks, a phone with an EatClub deal lying on the table between them

Party of One

Every offer on EatClub fed a whole table, but we only ever met the person who paid.

Most people don’t eat out alone. Nearly three quarters of dine-in transactions on EatClub involved two or more diners, yet the app was built around one. A single person found the offer, redeemed it and paid with their EatClub card. The rest of the group would benefit from the offer and settle with the host later on without ever opening the app.

The guests our existing users were bringing along were our most promising audience. They had watched EatClub work, eaten at the venue and felt the saving, which put them far closer to signing up than anyone scrolling past an ad.

The question was how to turn a seat at the table into a reason to join, and there was more than one way we could answer it.

Three friends at a café counter: one pays for the table by tapping a phone on the card reader while the others look on

Tasting Menu

We tested many bets before choosing one, and only one worked for everyone around the table.

A meal out gets shared at five moments: the plan, the invite, the table, the bill and the reflection after. We built seven concepts around them, from referral rewards to group polls to a community feed, and tested each one with diners against the same two questions: would it make their lives easier, and would they want to use it?

We found our diners were already doing the hard part. They showed EatClub off at the table and talked it up afterwards, but the enthusiasm rarely turned into a sign-up. Once the meal was over, a promise to download the app later tended to fizzle out.

…I go out with friends, I show them EatClub and they’re always keen. But once we leave, they forget about it. I don’t think any of them have actually used it.
User interview

Most of the concepts couldn’t close that gap. Our referral program rewarded only the person doing the referring, and diners felt uncomfortable pushing an app on friends when they were the only one who’d benefit. The social ideas fared worse. Nobody wanted a feed, plans were made in group chats rather than polls, and diners were clear that EatClub was a deals app, not a social one.

The group ideas came closest. People were already screenshotting offers into their group chats, and what they wanted was simple: everyone on the deal, each paying their own way. Splitting the bill scored highest on value, but it divided opinion and did little to bring new diners in.

Across all seven, the same thing held every idea back: each one relied on getting a friend onto EatClub. Deal sharing was the concept built around that step. It combined the group offer diners asked for with the shared reward our referrals had been missing, and put it in the hands of the person already at the table.

A diner at a table messaging three friends on their phones, each in their own bubble, to plan a meal together

A host could invite friends into their plans and see who was coming. Each new guest added to the whole table’s savings, so bringing a friend benefited everyone, not just the person who asked. Every guest could pay for themselves with their own card, and experience EatClub first-hand rather than hearing about it.

It worked for restaurants too. Groups paying separately had been redeeming an offer each, using up a venue’s limited offers on a single table. With deal sharing, one offer covered everyone, and a boost that grew with each new guest gave groups a reason to bring more people.

Two Sides of the Table

Sharing a deal took a couple of taps. Joining one took more than a dozen steps, and that's where most of the design work went.

The host’s side came together quickly. A host could share their deal straight after redeeming it, from their voucher, or from a reminder as their visit approached, then keep track of who had joined. The guest’s side was far harder, because it had to work for someone who might never have heard of EatClub.

The Share and Save screen: save up to 10% extra when you share and dine with friends, with buttons to send details or continue to the voucher.

Shipped host flow

More friends, a bigger saving

Straight after redeeming an offer, the host is invited to share. Every friend new to EatClub who joins adds to the whole table’s saving.

1 / 4

For a guest without the app, the path to the table was long. First they had to download EatClub and create an account, and the invite would only be waiting for them if the link survived the install. That got them into the plan, but not the saving. For the discount to apply, they also had to set up EatClub Pay: verify their phone number, add payment details, choose a card design, add the card to Apple or Google Wallet and verify again there. Every step was another chance to change their mind.

And all of that came before a guest had seen anything in return. Each step asked them to trust an app they’d only just heard of, on the word of a friend. So I proposed flipping the order: show the value first and ask for the commitment later.

The invite would arrive as a text from the host, building on the trust the guest already had in their friend. It would open on the web rather than in the app, leading with the plan and the saving, then answering what a newcomer would want to know: who EatClub is, how the saving works and how they’d pay. Only then would it ask for the download.

A text message from a friend, Jimmy, inviting the guest to Sad Coyote for 45% off, with a link preview to the invite.

Proposed guest flow

It starts with a friend

A text from a familiar name, with the venue, the saving and the host up front.

1 / 4

We went back and forth on it for a couple of weeks. My case was that a guest who had seen the saving first would be more likely to make it through the install. Leadership chose to send guests straight to the app, the simpler route on paper, and the web invite became a question we never got to test.

Sending guests straight to the app didn’t remove the risk so much as move it. Every new guest now had to get through the install, and that’s where things could break: a guest with the app but no account, a new guest who skipped sign-up, an invite lost during the install, a guest removed before they’d even joined. Each was a point where a willing guest could drop out of the plan without knowing why. Designing an answer for each one became most of the work on the guest’s side.

Opening Night

Diners took to sharing straight away. Asking hosts how it went showed us what was still in the way.

Deal sharing launched to every diner in Australia and the UK at once, and it found its audience in the first week. Of the guests who joined a shared deal, 61% were new to EatClub: the friends from the other side of the table who, until then, had left no trace. Around half of all guests went on to tap their own card at the venue.

A couple of weeks in, we surveyed the hosts who had used it, and the results backed the bet. Seven in ten said they were likely to use it again. The boost was the most common reason to share, but nearly half of hosts said they had shared to introduce their friends to EatClub, which told us diners were as keen to bring people in as they were to save.

Launch

61%of guests who joined in week one were new to EatClub
7 in 10hosts said they were likely to use it again
1 in 2guests paid with their own card at the venue

The survey also showed us what wasn’t landing. Close to half of hosts didn’t realise their guests could pay with their own card, the part of the feature that made it useful at the table rather than just a bigger discount. Others said the prompt to share reached them after the table had already ordered or paid, too late to bring anyone in. And some told us their friends had lost the invite after installing the app, the gap the web invite had been designed to close.

None of it was a reason to pull back. It was a list of places where the guest’s side still asked too much or explained too little.

Settling the Bill

Splitting the bill was ready to build. A shift in priorities set it aside a week before launch.

Splitting the bill was always meant to follow deal sharing. Guests would already be paying their own share of the table, and dividing a single bill in the app was a short step from there. We had it fully shaped, and the team was about to plan it into the next sprint.

A week before deal sharing launched, it was pushed back. The call came down to company goals rather than the work itself. Split bill was seen as an experience improvement, not something that moved a consumer goal, and deal sharing was expected to bring in new users on its own. The capacity went to a search and discovery revamp and to loyalty instead, with split bill to be revisited once deal sharing’s numbers came in.

My research had been raising doubts about it anyway. One question came up more than any other: why would someone download an app they had only just heard of, and hand over their card details, just to split a bill they could PayID in seconds? For a diner who already used EatClub, splitting in the app might have been a small convenience. For the new guests deal sharing was built to reach, it asked for the most trust at the moment they had the least reason to give it.

Why would I download an app I’ve just heard of, and hand over my card details, to split a bill I can PayID in seconds?
User interviews (paraphrased)

The host survey after launch pointed the same way. Only 3% of hosts had shared a deal to split the bill. They shared for the boost, to introduce their friends and to plan a night out, and none of those needed the bill divided any differently.

Host survey

Why hosts shared

Get the boost
65%
Introduce friends
47%
Plan a night out
19%
Try a restaurant
17%
Split the bill
3%

Hosts could choose more than one reason.

The Next Course

A year on, more tables are sharing than ever. The problems left to solve all sit after the invite.

Deal sharing has kept growing since launch. A year on, the number of guests accepting an invite each month has more than tripled, and the share of invitations that get accepted has nearly doubled. Hosts clearly want to share. What’s left sits on the guest’s side, and if I picked the feature back up, these are the problems I’d take on first, and why.

A year on

3.3×guests accepting an invite each month, compared with launch month
~2×the share of invitations that get accepted

1. Saying yes isn’t the same as sitting down

A new guest has to download the app and sign up before they can accept, then add a card before they can pay. Most never get that far. Of nearly 4,800 new guests who accepted an invite between late August and late September, fewer than half added a card within a week. On Android it’s close to none: since June, card-adds among guests have dropped from around one in five to almost zero, the biggest single leak in the flow.

That comes first. After it, I’d finally test the web invite against the path straight to the app, judged by how many new guests make a first payment rather than how many accept. That means tracking first payments properly before the test starts.

2. Guests can’t see what’s in it for them

Diners told us they wanted everyone on the deal and each paying their own way, and that’s what deal sharing gives a guest: their own share, on their own card, with the saving on top. It’s also the easiest part to miss.

When we surveyed hosts after launch, close to half didn’t realise their guests could pay with their own card. The share message was changed to lead with it soon after, but that survey is over a year old and asked hosts, not guests. Before redesigning the guest’s first screen around it, I’d want to know what guests actually understand when the invite lands.

3. We still don’t know what the boost is worth

Deal sharing launched to every diner in Australia and the UK at once, and the planned holdout never ran. There’s no way to separate the growth the boost drives from the growth the feature would have seen anyway. Holding it back for a share of hosts would show whether it works. Testing two or more boost levels would show whether the saving is set at the right level.

The hardest part was never getting people to share. Our diners had been doing that for us long before there was a way to share deals. The work now is making sure that once a friend says yes, nothing between their yes and the table gives them a reason to change their mind.

Next projectPrototyping at the Speed of an Idea