Proposal for unavailable time slots to be greyed out instead of not visible at all in booking page

[MinosChatzidakis]

Hello there, I have been using Calnode for some time now and even though it has been a pretty smooth experience, I would like to propose a new feature regarding the booking page of an event type, which I believe would greatly elevate the user experience.

More specifically, I would like to propose that the timeslots which are unavailable to be booked (for example because the host is unavailable or a booking has already occurred in said timeslot) would be greyed out instead of not appearing at all to the user, or at least that a choice would be given to the admin to decide how they wish to handle it.

I strongly believe that this would improve the user experience by a considerable amount, as it would communicate more efficiently the fact that the specific timeslot is unavailable for booking, and it would help avoid confusion on the end user's side (as to why some timeslots are not visible).

Thank you for the consideration and for this product you have built.

[shockalotti]

Thanks for the kind words, and for writing this up properly rather than just dropping a one-liner. It's a fair UX observation and I want to give you a real answer rather than a reflexive no.

The honest constraint first. GET /v1/event-types/{slug}/slots is public and unauthenticated. Right now it tells the world when a host is free. That already leaks something: if slots run 9:00, 9:30, then jump to 11:00, you can infer a meeting sits in between. What it doesn't leak is the frame. Nobody can tell whether 8am is missing because the host doesn't work then, or because they're booked.

Greying out unavailable slots supplies exactly that frame. Once the working day is visible, every gap inside it becomes a definite "this person is in a meeting", for the whole booking window, readable by anyone with the link. For a solo host with published hours that costs nothing. For a sales team it hands out a fairly precise calendar.

A smaller practical issue too. A slot can be unbookable for at least four different reasons: already booked, outside an availability rule, inside a buffer around an adjacent meeting, or too soon under minimum notice. Greyed out without a reason, that's noise. With a reason, it leaks more. And since slot interval became independently configurable in 0.6.0, a 15-minute interval across a 9-5 day is 32 buttons with most of them dead.

So, the question back to you: are your hosts' working hours already public knowledge? I ask because the answer genuinely changes my view. If Calnode is fronting something like a clinic, a tutor, or a service with posted hours, the grid leaks nothing and I think you're right that it reads better. If it's fronting a team's internal calendars, the same setting is a privacy regression wearing a checkbox. I'd rather understand which case you're in than ship an option that's quietly wrong for half the people who tick it.

Two things I think are worth doing regardless, because they address the confusion you describe without inventing a grid:

1. The empty and sparse states are too terse. "No available times." reads as a broken page rather than an answer. Naming the host and the date would land better.
2. Minimum notice is the genuinely confusing case. You look at today, see nothing until the evening, and there's no explanation anywhere. That's a policy rather than private data, so it's safe to state plainly, something like "bookings require 4 hours' notice". I suspect this accounts for a decent share of the "why can't I see those times" reaction.

Leaving this open. If a few people land here wanting the full grid for public-hours use cases, that's a strong argument for the opt-in version and I'll build it.

[MinosChatzidakis]

Very informational, thanks for taking the time to go through the constraints. I understand how this feature could lead to information leakage, however as the current version stands, it's not that hard for someone to infer the host's schedule just by taking a look at a couple of different days. In your example, if 8am is missing on, say, Tuesday but is available on every other day, one could tell that the Tuesday slot is already booked.

In my personal use case, Calnode allows interested parties to express interest and book an introductory meeting with the hosts. So it doesn't leak anything sensitive that I wouldn't like leaked. On the contrary, having the already booked timeslots greyed out creates a sense of urgency to the user to book a meeting, because it communicates the fact that there is traffic from other users who express the same interest in our service and the limited availability of the hosts. So to sum it up, there are no privacy concerns on my part.

I absolutely agree with your two points addressing possible confusion and I think they would be a great addition, clearing the air quite a bit for the users.

[shockalotti]

That's a fair push back and you've changed my mind on the main point.

You're right that the frame is already recoverable. If a host's hours are stable week to week, comparing a few days tells you where the day starts and ends, and anything missing inside it is a booking. And it's actually weaker than that: anyone polling the slots endpoint on a timer can diff consecutive responses and watch bookings appear, at exact times, today, with no greying involved. So greying changes how convenient and precise that inference is, not whether it's possible. I presented it as a categorical difference and it isn't one.

What survives is smaller: greying makes it effortless and exact for a casual visitor rather than something you have to deliberately go looking for. That still matters for an instance fronting a sales team's internal calendars, so I want it off by default. But it's no longer a reason to refuse, and you've given exactly the use case I said would change my mind.

So: yes, as a per-event-type setting, default off.

Your second point usefully narrows the design. You don't want every unavailable slot greyed, you want booked ones visible, because a visibly busy calendar signals demand. That's a much better target than "show everything that can't be booked". Concretely it means greying only the times blocked by a booking or a calendar conflict inside the host's offered hours, and not rendering the rest of the day at all. That also disposes of my worry about a 15-minute interval producing a wall of dead buttons, since only genuinely contested times appear.

One thing I'll deliberately keep out of it: slots that are unavailable purely because of the minimum-notice rule. Greying those would say "someone booked this" when nobody did, which corrupts precisely the signal you're after. Those get the plain-language explanation from point 2 instead.

Thanks for arguing the case properly rather than restating the request. Both of the smaller fixes are happening regardless, and I'll open tracking issues for these shortly.

[shockalotti]

Tracking issues opened: #19 for the opt-in greyed booked slots, and #20 for the two copy fixes (empty state, and explaining minimum-notice gaps). #20 is independent and will likely land first.

[shockalotti]

@MinosChatzidakis this shipped in 0.8.0.

Enable it per event type: Event Types → your event type → Visibility → "Show booked times as unavailable". Booked times then appear struck through in the slot list instead of being omitted, in place among the bookable ones, on the booking page, the reschedule page and the embed widget.

A few things about how it ended up, since your second point shaped them.

Only booked times are greyed, and that is enforced structurally rather than by care. The engine works out what is taken by running the availability pass twice, once normally and once with every busy interval ignored, and reporting the difference. It sounds indirect but it means a time outside the host's working hours, a time withheld by the minimum-notice rule, and a time lost to a host pool that cannot satisfy the routing mode are all absent from both passes and cancel out. They cannot be reported as taken, rather than merely not being reported today. Greying a slot says "somebody booked this", and I did not want that claim to be capable of being wrong.

Minimum-notice gaps specifically are not greyed, for the reason you'd expect: nobody booked those, so showing them as taken would corrupt exactly the signal you're after. Those get a plain explanation instead, which is #20 and next on my list.

Buffers do count as taken. If you have a buffer before or after meetings, the times inside it grey too. They genuinely cannot be booked, and from the visitor's side they are indistinguishable from the meeting itself.

It is off by default and set per event type. Your instance's hours are effectively public, so there is no cost for you; an instance fronting a team's internal calendars would be disclosing something real. The editor says so plainly while the setting is on.

Days that are now entirely booked stay openable rather than greying out in the calendar, so a full day shows you a list of struck-through times and "Every time on this day is booked." That reads better than a dead date, and it is the case your urgency argument is strongest for.

One thing it deliberately does not do: agents connected over MCP or the chat assistant still only ever receive bookable times. A struck-through slot on the page is unbookable everywhere else too.

Thanks for pushing back on the privacy objection rather than just restating the request. The cross-day inference point was right and it changed the answer.