Booking Page per Team Member

[kyfehr]

Not sure if it is in the roadmap, but is it possible to have a booking page for the team member, what shows all their appointment types, versus a booking link per appointment type only.
Edit: this is for customers to see, not the dashboard in admin interface. ie. goto Https://calnode.example.com/TeamMemberName vs a booking link to the event type only.

[shockalotti]

Good idea, and it's a genuine gap. Right now every bookable URL is per event type (/book/{slug}), so if you want to give someone a single link that says "here's everything you can book with me", there isn't one. You end up pasting three links into an email signature.

The data side is easy. Event types already record their owner, and they already carry is_public and is_active flags that control whether they show up publicly at all. So "list this person's bookable event types" is one query, and the flags mean people keep the ability to have unlisted event types that only work via a direct link. That part is a small amount of work.

The interesting question is the URL, and I'd like your opinion on it since you proposed the shape.

Your example is calnode.example.com/TeamMemberName, a bare name at the root. That reads best, and it's what Cal.com does. The cost is that the root of a Calnode instance is already fairly busy: /admin, /book/, /manage/, /room/, /embed.js, /booking.css, /avatars/, /branding/, /assets/, /robots.txt, /favicon.ico, /healthz, /readyz, /version, /mcp, /oauth/, /.well-known/ and /v1/. Routing handles that fine today, but it means two ongoing obligations: a reserved-word list so nobody can claim a handle that collides, and a rule that every future top-level route has to check against existing handles or it will silently shadow somebody's live page.

The alternative is a short prefix, something like /u/alice. Uglier, and permanently immune to the whole problem.

I lean toward the bare version with a reserved list, because this is a link people put on business cards and the prefix is a visible tax forever. But it's the kind of decision that's very hard to reverse once people have shared their links, so I'd rather hear from the people who'd actually use it before committing.

A few other things it needs, noted so they don't get discovered halfway through: a handle field on the user profile (unique, URL-safe, editable), a decision about what happens to the page when someone is archived (I'd 404 it rather than leave a dead booking page up), and a choice about whether the page is a plain list or shows duration, price and location per event type. I'd lean toward the richer version, since the whole point is helping someone choose.

Would a team-level page be useful to you as well, or is per-person enough for what you're doing? Teams already exist as a first-class thing here, so /team-name listing that team's shared event types would be a natural companion, but I don't want to assume you need it.

[kyfehr]

The /u/ is not a deal breaker for me because my links will be on a website and the booking page will be linked there so not an impact on a business card for me. Ultimately I think it should be built in the way that make it easiest to maintain so that it does not become a complicated process to support.

I would love to have a teams page with all the options and with rich details.

I like the idea of 404ing in the case of an archive - it would be nice to create a custom 404 page so that it may be redirected back to a teams page??