Booking pages with the video room built in.
For consultants, agencies and small teams who run booked calls. The confirmation email carries the join link, and it stays right if the meeting moves.
No downloads. No plugins. One link from booking to meeting.
- Invitee time
- 9:00 am · Thu 14 Aug · Bengaluru
- Host time
- 1:30 pm · Thu 14 Aug · Sydney
People whose calendar is their business
If a stranger booking time with you is a normal part of your week — and the meeting happens by video — this is the shape of tool you are looking for.
Consultants and coaches
One link in your email signature. Clients book, and the room is already waiting.
Agencies and studios
Round robin across the team, collective slots when everyone must be free, and buffers so nobody's day becomes a wall.
Sales and success teams
A routing form sends each enquiry to the right person, and every booking arrives with a room and a reminder.
Anyone running client calls
Reschedules keep the same link. Cancellations close the room. Nobody hunts for a missing join URL at 9:02.
No second link to paste
Most teams run a scheduler and a video product side by side, and glue them with a field in a confirmation email. That glue is where meetings get lost — the link arrives late, points at the wrong account, or changes when the time does.
- 1
A booking is confirmed
The moment a slot is taken, Meet Buddy creates a secure meeting room with a human-readable code. Nothing has been joined yet — the room is simply ready when you are.
- 2
Everything carries the same URL
The confirmation email, the ICS attachment and the calendar event all quote that one join link. There is no step where somebody has to remember to add it.
- 3
It stays true afterwards
Rescheduling keeps the code, so the calendar entry someone already accepted still opens the right room. Cancelling closes it, so an old link never quietly lets a stranger in.
And because creating a room is a line in the database rather than a call out to a video server, a booking never fails because the video is having a bad day.
Scheduling that does the awkward parts
The interesting work in a scheduler is not the calendar grid. It is buffers, notice, caps, overrides and timezones — the rules that stop a day filling up wrongly.
Availability that survives a calendar
Named weekly schedules, date-specific overrides, and a rolling or fixed date range. Buffers either side, a minimum notice, start-time increments, and caps per day, week or month.
Four ways to share a slot
One-on-one, group with a capacity, collective where every host must be free, and round robin distributed by least-recently-booked, even split or priority. Plus single-use links for the one-off.
Right time in both countries
Invitees pick their zone or have it detected; hosts keep theirs. Every slot is generated per calendar day rather than per week, which is the only way a fixed 9:00 stays 9:00 across a daylight-saving change.
Ask before they book
Short text, long text, select, multi-select, phone and checkbox questions, required or not, alongside the built-in name, email and guest fields. Routing forms send a respondent to the right event type or straight out to a URL.
Reschedule without a new link
Cancel and reschedule run through signed links with a reason captured, and your notice policies are enforced on the server rather than suggested in the interface. A reschedule keeps the meeting code — so the invite already sitting in somebody else's calendar is still correct, and you never send a correction email.
Reminders, follow-ups, webhooks
Confirmations, reminders at the offsets you choose, follow-ups after the end, and cancellation notices. An ICS attachment on every one, a calendar feed per member, and a webhook when you want to tell something else.
09:00 is a wall clock, not an instant
Availability is stored as a weekday, a number of minutes past midnight, and an IANA zone — never as a UTC instant. Slots are generated by converting per calendar day, because a fixed local 09:00 sits at a different UTC instant either side of a transition, and the day the clocks move is 23 or 25 hours long.
Every one of those conversions lives in a single module with its reasoning written down, and no date library is installed. That is a deliberate constraint: the bug where a Monday morning quietly shifts by an hour for six months of the year is the one nobody notices until a customer misses a call.
A real room, not an embed
The video is ours, not a window onto somebody else's product. Guests join from the same link already in their calendar — no account, no download, no app store. Access is granted on the server every time, so a host is a host because our records say so, never because a browser claimed it.
A green room first
Pick a camera, a microphone and a speaker, watch your own level meter, and see a permission error explained rather than swallowed — before anyone in the meeting sees you at all.
A lobby with a door
Anyone who is not a host or a confirmed invitee knocks. Hosts admit or deny, lock the meeting once everyone is in, and can mute, remove or promote a participant to co-host.
Screen share that says who
A presenting indicator, and a takeover prompt when someone else already has the screen. Active-speaker detection with a speaking ring, and a connection-quality reading on every tile.
Grid, spotlight, sidebar
Three layouts and a pin, because a workshop and a one-on-one are not the same shape. Pinning is a property of your view, not an instruction to everyone else's.
Chat that outlives the room
In-meeting chat, raised hands and reactions. The chat is written to the booking's record, so the room closing is not the end of what was said in it.
Breakouts and polls
Split into rooms, assign people, broadcast a message and pull everyone back. Polls and Q&A run in the main room, and an attendance report says who joined, when, and for how long.
One deployment, end to end
The booking page, the scheduling rules and the meeting room are one application talking to one media server. There is no second product to hold an account with, no second bill, and no vendor's link to paste into a confirmation email.
And if you would rather it were literally yours: the application and the media server are both yours to deploy. There is a REST API with a published OpenAPI document, webhooks for telling anything downstream, and a calendar feed per member. Nothing here is a walled garden.
To be plain about which one this is: Create your booking page signs you up on this deployment, not on a server of your own. Running your own is a separate thing, and the same software.
Inline, popup, or a link
A booking page is a page, so embedding it is an iframe rather than a script that rewrites your DOM. Nothing loads from us until someone actually opens it.
<iframe src="https://meetbuddy.radioworkflow.com/your-workspace/intro-call?embed=inline" width="100%" height="720" frameborder="0" title="Book a call" ></iframe>
Book a time. The room already exists.
Set up a booking page in a few minutes. The first meeting anyone books on it already has a room waiting.