What Happens After the Booking

The booking is the easy part. People hit confirm, the calendar invite goes out, and everyone has a place to be on Saturday at three. The harder question is what happens after that — once people are actually in the room, on the court, or around the table.

We've been working through this question by talking to three different kinds of hosts: a football host running a weekly five-a-side, a friend hosting a dinner for twelve, and a guitar teacher running back-to-back lessons. They book through completely different mental models. But the moment the booking is done, each of them needs the platform to do something. And what they need has almost nothing in common.

The four facets every experience holds, after the booking is done.

Coordination. Measurement. Interaction. Log. Every experience holds these four — but how each one gets filled depends on what the experience actually is. The same slot looks like a tournament bracket for one host, a dinner menu for another, and a set of lesson notes for the third. Here's how that plays out.

The Football Host Needs Teams

Ten people show up. The first thing the host does is split them into two sides. Not randomly — they want it fair, they want the keeper to be someone who's actually played in goal before, they want to balance the team that won last week against the team that lost. Then a match happens. Then a score gets recorded.

For this host, the moment after the booking is a coordination problem first and a measurement problem second. The platform needs to help draw the teams (or at least make it easy to record who ended up on which side), and then it needs to capture what happened — the final score, who scored, who was there.

Most of this content is generated by the activity itself. Football produces goals; the platform's job is mostly to log them.

The Dinner Host Needs a Menu and a Schedule

Twelve people are coming over for dinner at seven-thirty. The host has a starter, two mains, and a dessert. Three of the guests are vegetarian. One is bringing wine, one is bringing bread, two are bringing nothing. There's no score to keep. Nobody's going to win.

What this host needs is the opposite of what the football host needs. They don't want a leaderboard — that would feel hostile to the point of the evening. They want a place to pin the menu, the dietary notes, and the who-brings-what list. Maybe a rough timeline so the courses don't pile up. Maybe — if the conversation stalls — a couple of prompts to keep the table moving.

Almost none of this content is generated by the activity. A dinner doesn't produce a score, and it doesn't produce a roster. It produces a memory and some photos. Everything else has to be supplied as scaffolding by the platform, and the host fills it in.

The Guitar Teacher Needs Continuity

A student arrives for their fourth lesson. The teacher needs to remember what was covered last time (barre chords, Wonderwall, the F major struggle), what the student was supposed to practice this week (the chord changes, slowly, with a metronome), and what to start today (fingerpicking patterns, finally).

For this host, what matters is what the experience leaves behind. A guitar lesson doesn't need a leaderboard either. It doesn't need a menu. It needs a small log — what we did, what to practice, what's next — that survives until next week and shapes what happens then.

The activity produces this content (the lesson generates the notes), but only if the platform makes it easy to capture in the moment.

Same Architecture, Different Density

Three hosts. Three completely different needs after the booking is done. But they're all asking the platform the same underlying question: how do you give shape to the thing that's about to happen?

Football: heavy on team coordination, heavy on score capture, light on everything else. The activity does most of the work — the platform just needs to log it well.

Dinner: heavy on menu and schedule scaffolding, light on measurement (intentionally), some optional conversation prompts. The platform does most of the work — the activity provides the people and the food.

Guitar lesson: light on coordination (a lesson plan template), nothing to measure, rich notes that carry across sessions. The activity and the platform meet in the middle — the teacher generates the content, the platform makes it easy to keep.

Why the Same Slot Has to Hold All of This

It would be tempting to build a separate product for each of these — a tournament tool for football, a dinner planner for hosts, a lesson tracker for teachers. That's how most software in this space tends to evolve: one tool per use case, none of them connecting. But the result is that hosts who run multiple kinds of experiences have to switch between three tools, and the data never travels with them.

The bet we're making is that one architectural slot can hold all of this — as long as we accept that the slot looks different depending on what kind of experience is filling it. A football match and a dinner party are not the same thing. But they're both experiences. They both need something after the booking is confirmed. And the platform that hosts the booking is the right place to host whatever comes next.

That's also where it ties back into the longer arc. A community of football players accumulates a season's worth of scores into a leaderboard. A community of friends who eat dinner together once a month accumulates a photo album. A community of guitar students accumulates a portfolio. We've written before about how communities derive value over time. The point of this post is that the raw material of that value comes from each individual experience — and giving each experience a place to leave its trace is the work that makes the rest of it possible.

What We're Building First

Of the three host stories, the dinner host is the one Sledge serves least well today. A football host can already record a tournament result on the Scores tab — we proved that with a real event last week. A guitar teacher still needs a lightweight way to keep lesson notes and continuity, and that's on the roadmap. But a host throwing a rooftop party or a Sunday dinner currently gets nothing once the booking is done — and gatherings are where we have the most real-world testing momentum. So that's where we're starting.

The first version is small. A handful of conversation prompts. A simple way to mark who's bringing what. A place to drop the photos after. Nothing clever. The point is to find out whether hosts open it during the event — which is the only honest measure of whether the slot is filling a real need.

We'll come back to the broader framing — how all of this connects into a positioning thesis about Sledge as the layer that gives shape to in-person time — in a later piece. For now, the work is more concrete: name the slot, build it for the host who needs it most, and see what happens.

Try Sledge

Available on iOS and web. Android coming soon.