What scheduling tools forgot about hospitality

There's a word that comes up when I talk to lawyers and executive coaches and senior advisors about scheduling. It comes up by accident, in passing, in the middle of a sentence about something else. The word is guest.

"When I'm scheduling with a client, I think of them as a guest in the conversation."

"My senior partners treat the people they meet with as guests, not as appointments."

"You don't hand a guest a self-service kiosk."

It's not a word I went looking for. It just shows up, again and again, in the language people use when they describe the way they wish their scheduling worked. And once you notice it, you can't unnotice it — because almost no scheduling software has ever been built with hospitality in mind.

Hospitality is one of those concepts that feels soft until you try to define it precisely, at which point it gets sharp. It's the difference between a hotel that hands you a key and a hotel where the bellman walks you to your room. Between a restaurant that hands you a menu and one where the server asks how hungry you are tonight. Between a meeting offered in the form of three specific times and a meeting offered in the form of a link to someone's open availability.

In every one of those pairs, the second option costs more. It takes more attention, more effort, more thought per interaction. And in every one of those pairs, the second option signals something the first one can't: I have considered you specifically.

For most of human history, that signal was the default in professional relationships. You didn't have to opt into it; it was just what people did. Of course you offered a few specific times. Of course you wrote the note by hand. Of course the email came from your actual address. There wasn't a category of professional interaction where bulk efficiency was prized over the small dignities of a considered transaction.

Then scheduling software arrived, and it changed the default.

It didn't do this maliciously. The early scheduling tools were built for specific use cases — sales teams running hundreds of demos a month, recruiters screening dozens of candidates, customer support reps fielding constant requests. In those contexts, hospitality wasn't a value being abandoned; it had never been the goal. The goal was throughput. Get more meetings on the calendar with less friction. A booking link is the right tool for that job, and the early tools did it brilliantly.

The problem is what happened next. Tools built for high-throughput scheduling became the defaults for all scheduling. The sales team's tool became the marketing team's tool became the consultant's tool became the executive coach's tool became the lawyer's tool. Each step of the way, a tool optimized for one kind of relationship was applied to another kind of relationship — and at each step, a small amount of hospitality was traded for a small amount of efficiency.

Most of the trades looked reasonable in isolation. Why would I manually copy times into an email when I can just send a link? Well — because for some recipients, the link is the wrong form of the ask. Why would I use my real email address when the tool can send a polished invite for me? Well — because for some recipients, the polished invite reads as impersonal in a way the plain email wouldn't. Why would I think about each scheduling interaction individually when I can automate them all the same way? Well — because some interactions deserve the individual thought, and we forgot how to tell which ones.

A whole generation of professionals has come up assuming that the booking link is just how scheduling works now. It isn't. It's how scheduling works for one specific kind of interaction, and it got generalized into a default it was never designed to be.

You can see the cost of that generalization if you watch carefully. Watch a senior consultant compose an email to a long-standing client. They start to drop their Calendly link into the email. They pause. They delete the link. They open their calendar, look for three times, type them into the email manually, send it. They've just done with effort what the software was supposed to automate, because the software's version of automation was the wrong shape for the relationship.

Multiply that small moment by the millions of high-trust professional scheduling interactions happening every day, and you get a picture of an industry that built a tool that worked for some people and then handed it to everyone, expecting everyone to use it the same way. And mostly, they have — because the alternative was to keep doing the work manually, which doesn't scale either.

The hospitality wasn't lost on purpose. It was lost because nobody built a tool that automated the hospitable version of scheduling. The only automation on offer was the booking-link version, and the booking-link version was better than nothing, so people used it — even when it didn't fit.

I think we can do better than that, and not by abandoning automation. Quite the opposite. The same calendar integrations, the same one-click bookings, the same automatic invites and confirmations — all of it works just as well in service of a hospitable scheduling pattern as it does in service of a transactional one. The mechanics are the same. The social transaction underneath them is what differs.

That's what Proffer is. Not a replacement for scheduling software, because scheduling software has done genuinely useful work for the markets it was built for. Just a different shape of the same tool, for the markets that were left out. The lawyers, the coaches, the consultants, the advisors. The professionals whose work has always been built on the small ritual of offering three times — and who, for the last ten years, have been doing it by hand because nobody automated their version.

We're automating their version now. And it turns out, when you do, the people on the receiving end notice. Not because anything dramatic happened — but because the meeting they got invited to felt like it was extended by a human being who thought about them. Which, of course, it was.

Hospitality wasn't a bug. It was a feature we accidentally stopped shipping.