Cases and lessons

The tournament spreadsheet: four lessons on organizing a padel tournament

Why a well-organized tournament can still feel chaotic, and what we learned building the system that brings order to it. Americanos, live brackets and courts that show up as free when they aren't.

An Americano isn't a random draw: it's a combinatorics problem where every player has to face everyone else without repeating a partner or sitting out more than their share. And the chaos you feel on the court almost never comes from the bracket, but from players, scoreboards and courts not looking at the same live source.

When a club calls us, it almost never says "I need software." It says something else: that tournament Saturdays are chaos, that nobody knows when they're playing, that the person who sets up the matchups can't also run the bar. The software comes later. First you have to understand why a well-organized tournament can still feel chaotic.

Here are four things we learned doing it.

An Americano isn't a random draw. It's a combinatorics problem.

The first time we looked at an Americano spreadsheet, we understood why it's always put together by the same person: they're the only one who knows how.

With fixed pairs it seems simple, but it isn't. You have to assign the courts so that nobody plays three in a row while someone else waits forty minutes. And you have to do it looking at the whole tournament, not match by match — if you decide each round as it comes, by the fourth there's no fair split left and someone walks off.

And there are some uncomfortable truths worth stating up front. With eight players and two courts, someone sits out every round. It's not a system error or an oversight by the organizer: it's arithmetic. What you can do is make sure it falls on everyone equally, and that the organizer knows it before starting instead of finding out when someone complains.

In the individual Americano, the problem takes a different shape. There, fair means everyone plays with everyone as a partner and against everyone as an opponent, the same number of times. That has a known solution, but you're not going to work it out by hand on a Saturday at nine in the morning with people waiting.

One detail that only shows up when you play: if matches are played to an even number of games, ties exist. It seems obvious written down here. It isn't when the system you built rejects a 3-3 and there are two pairs standing on the court waiting for you to let them enter the score.

"When do I play?"

It's the most repeated question at any tournament. People ask the organizer over and over, and every time it pulls them away from what they were doing.

The answer isn't one more screen. It's letting players answer it themselves, from their phone, without installing anything or creating an account. They see their next match, which court, against whom, and if the tournament runs half an hour behind, they see it pushed back.

The side effect was the interesting part: when the bracket is live on everyone's phone, spectators start following matches that aren't their own. People who came to play at eleven stay to watch the final. We didn't plan that; we watched it happen.

A scoreboard that lies is worse than no scoreboard

We put screens on the courts with the live score and thought it was solved.

It wasn't. Many clubs keep the score somewhere else — an app they already use, a notebook, the coach's head. So the screen showed a zero-zero that nobody was going to update all night, right in front of everyone.

An empty screen doesn't bother anyone. A screen that states something false does, because the audience believes it. We had to separate two things we'd been treating as one: broadcasting a match and showing it on the court's screen. You can want one without the other, and the club decides which.

The same lesson showed up in another form. When a court had no match, the screen announced "the next one." It sounded useful. The problem is that to do that you have to pick which one is next, and if you pick wrong you announce the wrong match with two last names in big letters. We removed the feature. Now the screen shows what it was sent and, if it wasn't sent anything, it doesn't make things up.

The court showed up as free, and it wasn't

This one took us a while to understand, and it's the most boring of the four. It's also the one that costs the most money.

A club doesn't stop operating because there's a tournament. People keep calling to book. So the system has to know, at the same time, which courts are committed to the tournament and which can be rented out — and it has to know that down to the time slot, not the day.

It happened to us the other way around: matches saved in advance that held their court forever, not for their hour and a half. The calendar showed the slot as free, the booking bounced, and nobody understood why. One of the club's courts stopped being sellable without a single error showing up on any screen.

A booking has to end. It seems trivial until you haven't built it in.

What we learned

None of these four problems was, at its core, a software problem. They were operational problems that software can solve if someone sits down to look at how a real club works.

That's why we don't like showing off features. A list of what a system does tells nothing to someone who has sixty people at the club on Saturday and only one pair of hands. What does say something is this: once the tournament starts, the organizer can be at the bar instead of in the spreadsheet.

Do you run a club and does any of this sound familiar?

Write to us. You don't need to know what you need — we'll figure that part out together, and the diagnosis is free.

We'll be in touch soon.

We solve this in Custom software and ERP →