The field that asked a question and then shrugged
For a long time, the schedule field on a form did one honest thing: it asked when someone was free, and then it shrugged.
The visitor would tick a few boxes. Mornings are good. Tuesday or Thursday. "Whenever works, really." That little bundle of preferences landed in a submission, and from there it was a person's problem. Someone on your team opened it, looked at a calendar, picked a time, typed an email, waited for a reply, and — if the planets held — put something on the books two days later.
That's not a scheduling feature. That's a to-do disguised as one.
So we taught the field to finish the job.
Path one: the visitor picks an open time
Switch a schedule field to auto mode, and it stops asking when might you be free and starts showing here is when we actually are.
The form renders a live picker. The times in it aren't a guess — they're the open slots on your assigned staff's calendars, pulled the moment the page loads. The visitor picks one. They submit. The meeting books. The calendar event appears, the video link generates, the confirmation emails go out to both sides, and the whole thing is wired into your CRM as a first-class booking before the visitor has switched back to their inbox.
There's no reply-to-schedule, no "let me get back to you" — the booking happened while they were still on your site.
And if two people grab the same 2:00 on a Thursday? The booking step re-checks live availability at the last second and routes to whoever's actually free — or tells the visitor that time just went, cleanly, instead of double-booking your morning.
Path two: when a human should look first
Auto mode is the right call when your calendar is the source of truth. But plenty of meetings shouldn't book themselves.
A custom job walk-through. A first consult where you want to read the request before you commit an hour. For those, leave the field in its original mode: the visitor states their availability, in their own words, and that opens a proposal.
Here's the round-trip. The visitor submits — "mornings, Tuesday or Thursday, here's what the job is." Your assigned staff get a notification and open Meeting Proposals in the dashboard, where they see the request next to the open times that fit it. They pick up to three. The visitor gets an email with those three times and one link. They click one. It books.
It ends in the same first-class booking — the calendar event, the video link, the CRM activity, all of it. The only difference is that a person stood at the gate for a moment and chose to open it.
Who the form belongs to
Both paths run on one quiet idea: a form has owners.
In a form's settings, you assign staff to it — individual people, or a whole department or team that quick-adds everyone in it. Assign the HR group to a job application. Assign the PM and the install manager to a service request. Those assignees are the ones who get notified on every submission, the ones who manage it, the ones who can turn it into a job — and, for a scheduling form, the ones whose real calendars the meeting books against.
It's a general idea that happens to make scheduling work. The same assignment that routes an HR form to HR is the thing that knows whose Tuesday morning is open.
It only books when you're set up to book
The booking behavior rides on your scheduling plan. With it, the field books and proposes. Without it, the field does exactly what it always did — captures availability for a human to act on — so nothing breaks and nothing surprises you. Assigning staff to a form is free and always on, because routing a submission to the right people is just good plumbing.
A schedule field used to ask a question and leave you holding the answer. Now it asks the question and brings back a meeting. Pick the path that fits the meeting, and let the form do the part that was never really yours to do by hand.