Running a 60-team baseball tournament is seven jobs happening at the same time: entries, payments, pools, brackets, field assignments, communications and results. A small event survives because one person holds all seven in their head. A 60-team event does not, and the failure is never the tournament itself — it is that two of the seven disagree and nobody finds out until a team shows up at the wrong field.
This is what each job actually is, where it usually lives, and the point at which that arrangement stops working.
What actually breaks at 60 teams?
Not the games. The reconciliation between systems.
At twelve teams you can hold the whole event in your head. You know who has paid because you remember the four who have not. At sixty teams there are roughly 180 pool-play games to place, six to ten fields to keep full, sixty head coaches expecting an answer inside an hour, and a payment list nobody can recite. The event does not get harder in proportion to the team count — the coordination does, because every system you run has to agree with every other one.
The specific things that go wrong, in the order directors usually hit them:
- A team is in the schedule that never paid. Entries and money live in different places, so nothing stopped it.
- A field gets double-booked. The schedule was edited in two copies and the wrong one got published.
- Sixty coaches get a group text. Somebody replies-all. Now you are running the event from your own notifications.
- A bracket goes out with a stale seed because pool results were entered somewhere the bracket does not read from.
- Sunday's results never get posted, so the teams that travelled for exposure got nothing for it.
None of those is a software problem in isolation. All of them are the same problem: two records of the same fact.
What has to be decided before entries open?
Everything that a coach could later argue about. Publish it, then do not change it.
| Decision | Why it must be before entries, not after |
|---|---|
| Divisions and age cutoffs | A team that enters the wrong division and gets moved is a refund conversation |
| Game guarantee | "Three-game minimum" is the single most-asked question. It also constrains your schedule |
| Entry fee and what it covers | Umpires, balls, awards — say which. See what to charge per team |
| Refund and withdrawal policy | The date after which money is not coming back. Publish it or you will argue it |
| Rainout policy | Including what happens to fees. Write it now, not at 6am Saturday |
| Tiebreakers, in order | Head-to-head, runs allowed, run differential, coin flip — the order is the whole argument |
| Roster and age verification rules | What you will actually check, and when |
| Field rules | Run rules, time limits, drop-dead, pitching limits |
The tiebreaker order is the one people skip and the one that ruins a Sunday. Write it as an ordered list, publish it on the event page, and when a coach disputes a seed you point at the page instead of adjudicating.
Who needs to know what, and when?
Three audiences, three different messages, and the mistake is sending all three the same one.
- Head coaches need the schedule, the field, the rules and any change. They need it somewhere permanent they can re-check at 6am, not in a text thread they have to scroll.
- Parents and families need the schedule and directions. They do not need operational detail and they should not be in a channel where they can reply to sixty people.
- Your own staff — field marshals, scorekeepers, umpire assignor — need assignments and the ability to report a result.
A group text serves the first audience badly and the other two not at all. The practical minimum is a published schedule page that is always current, plus one outbound channel where you can send a change to every head coach at once without opening a reply-all.
What do you run on Saturday morning?
One screen showing what is happening now, and one person who is not umpiring, scorekeeping or coaching.
The Saturday job is exceptions, not operations. The schedule runs itself if it was built properly; what needs a human is the game that ran long, the field that flooded, the team stuck in traffic, and the coach who wants a ruling. If the director is also running a scoreboard, the exceptions queue silently.
What the director needs in front of them:
- Which games are in progress and which are running behind
- Which fields are free, and when the next one frees up
- Results that have come in, and which pools are now decided
- A way to push a change to every affected coach in under two minutes
The last one is the difference between a field change costing you four minutes and costing you an hour.
When does a spreadsheet stop being enough?
At the point where more than one person needs to see it, or where the same fact lives in two files.
A spreadsheet is genuinely the right tool for a small event, and anybody telling a first-year director to buy software is selling them something they do not need yet. It stops being the right tool at three specific moments:
- When a second person needs to act on it. A spreadsheet has one editor in practice. The moment a field marshal needs the current schedule, you are now a human API.
- When entries and money are in different files. This is the one that costs real money, because the gap is invisible until you reconcile.
- When a change has to propagate. Move one game in a spreadsheet and you have moved one cell. The published schedule, the affected coaches and the bracket do not know.
The honest version: most directors should run their first two events on a spreadsheet and a form. The third one is where the arithmetic changes.
The seven jobs, and where each one breaks
This is the table worth keeping.
| Job | Where it usually lives | What breaks |
|---|---|---|
| Entries | A Google Form into a sheet | No validation — wrong divisions, missing contacts |
| Payments | Venmo, Zelle, checks | Nobody can say who has paid without reconciling by hand |
| Pools | A spreadsheet tab | Edited in two copies; the wrong one gets published |
| Brackets | A bracket tool, separately | Reads stale seeds because pool results live elsewhere |
| Field assignments | A whiteboard or a printout | Not visible to anyone not standing in front of it |
| Communications | A group text | Reply-all, no history, no way to reach one division |
| Results | Someone's notebook | Posted late or never, so travelling teams got nothing |
Read down the right-hand column and every entry is the same sentence: the record exists in a place the rest of the event cannot reach.
Questions directors ask
How many fields do you need for 60 teams?
It depends on your game length and guarantee, but the arithmetic is fixed: fields × usable hours ÷ slot length = games per day. With a 1h45m slot and ten usable hours you get about five games per field per day. Sixty teams with a three-game guarantee is 90 pool games, so two days at six fields is roughly the floor. The scheduling post works a full grid.
Should we take entries before the schedule exists?
Yes, and you almost have to — you cannot build pools without knowing who is in them. What you should not do is publish a schedule before entries close, because every late entry then forces a rebuild. Close entries, build pools, publish once.
What is the single highest-leverage thing to fix first?
Put entries and payment in the same place. Everything else on this page is an inconvenience; that one is the only item that loses you money without telling you.
Do we need software, or better process?
Usually better process first. A director with a disciplined spreadsheet beats a director with a platform they have not set up. Software earns its place when the event outgrows one person's attention — and it is worth being honest that at 60 teams it usually has.
Does the event website actually matter?
More than for most sports businesses, because teams find events by searching for them. A page nobody can find costs you entries before the season starts, which is why our tournament build treats search as structural rather than an afterthought.
If you are running an event at this size, the question worth asking is not which tool to buy but which two records currently disagree. Usually you already know. We build the event site and the back office behind it as one thing — registration, schedules, brackets, field assignments and the communications that go out when a field changes — and entry fees land in your own Stripe account. See what that costs, or have us build you a free mockup of your event's site first.