How to Connect Ruby Receptionists with Cal.com (And Stop Worrying About Double-Bookings)

If you're using Ruby Receptionists to handle inbound calls, you already know the value of having a real human answer the phone. But there's a moment in almost every Ruby call where things can get awkward: the caller wants to book an appointment, and your receptionist has to figure out when you're actually free.

That's exactly the problem Cal.com solves. Give Ruby a single booking URL, and their receptionists can check your live availability in real time, fill in the caller's info, and lock in the appointment, all while staying on the phone. The caller never has to see a scheduling link. They just get told they're booked (and get reminders from Cal, so they don't forget the meeting).

This guide walks you through how the integration works and covers the two most common setups we see: team round-robin with priority routing (when you have multiple reps and want the best one to get the first shot), and form-based routing (when you need to send callers to the right person based on what they say on the call).

How Ruby + Cal.com actually works

Ruby's receptionists are trained to use web-based scheduling tools during calls. The way it works in practice is straightforward:

1. Caller rings in — Ruby receptionist picks up
2. Receptionist opens your Cal link — Sees live availability
3. Fills in the booking — Caller's name, email, reason
4. Appointment confirmed — Your reps and your customer get the notification

The receptionist is essentially acting as a human middleman between the caller and your Cal.com booking page. They collect the information, navigate the booking flow, and submit it. You get a confirmed appointment in your calendar, and the caller gets a human experience they trust.

Here's the real-world version: a home services contractor was getting flooded with inbound calls. They hired Ruby to handle the overflow and needed their Ruby receptionist to book calls directly with their sales team. But they didn't want Ruby sharing four different personal calendar links — they wanted one URL, smart distribution, and no double-bookings.

The answer is a Team Event with Round Robin + Priority in Cal.com.

Step 1: Create a Team

In Cal.com, go to Teams in the left sidebar and create a new team. Give it a name like "Sales Team" or "Service Scheduling." The Teams function in Cal allows you to manage bookings for a group of people.

Step 2: Invite your team members

From your team settings, invite each team member by email.

This step is critical — each person must accept the invitation via email before they'll show up as available hosts. Once they accept, they also need to connect their calendar to their Cal.com account.

Team member checklist: Each member needs to: (1) accept the team invitation, (2) connect their calendar to Cal.com, and (3) toggle on that calendar for conflict checking. All three steps, for every person.

Step 3: Create a Team Event Type with Round Robin

Inside your team, create a new Event Type.

You will find your team booking area to the right of your Personal booking area in Cal.

When selecting the scheduling type, choose Round Robin. This distributes bookings across available team members automatically.

Step 4: Set priority rankings for each host

In the assignment section for the event booking, scroll to "Round-robin hosts" and assign a priority level to each person. Cal.com always tries to book the highest-priority available rep first. If that person is busy, it moves to the next priority level. Only if everyone at higher priority levels is unavailable does it cascade down.

Step 5: Copy your team booking URL and give it to Ruby

Once published, you'll have a single booking URL like cal.com/team/[your-team]/[event-name]. Give this to your Ruby account manager. When a call comes in, the receptionist opens it, sees real-time availability across your whole team (prioritized automatically), and books the slot.Scenario 2: Route callers to the right person based on what they say

Sometimes you may want more granular control of who gets booked. You might need callers routed to a specific rep by name, to a product specialist, or to the right regional team.

This is what Cal.com's Routing Forms are built for. Instead of giving Ruby a direct booking link, you give them a form URL. The receptionist fills in answers based on the call, and the form automatically directs to the right booking page.

How to build the routing form

Go to Routing Forms in your Cal.com sidebar and create a new form.

Add the questions your receptionist will answer on behalf of the caller. For example:

• "Did the caller ask for a specific team member?" (Dropdown — routes to named rep)

• "Which product or service did the caller mention?" (Dropdown — routes to specialist)

• "What city or region is the caller in?" (Dropdown — routes to regional team)

• "Caller's name" (Text — passed to booking confirmation)

• "Caller's email or phone" (Text — passed to booking confirmation)

Setting up the routing rules

1. Add a rule for each named rep — "If [team member] equals [Name]" → route to that person's event type.

2. Add a rule for each product or service — "If [product] equals [Product Name]" → route to the specialist's booking page.

3. Add a rule for each region — "If [city/region] equals [Region]" → route to the correct regional team event.

4. Add a default fallback — Always set a default route for when none of the conditions match — typically your main round-robin team event.

What it looks like for Ruby

The receptionist opens the routing form URL, answers the questions based on the call, and submits. Cal.com handles the routing — the receptionist gets taken directly to the right booking page.

Pro tip: Use dropdown fields instead of free-text wherever possible. This makes it easier for receptionists to select quickly and prevents routing errors from typos.

Copy the published routing form URL and provide that to Ruby. Your URL will look like: cal.com/forms/[your-form-id]

Quick-reference checklist before you go live

• Every team member has accepted their Cal.com team invitation

• Each person's Google or Outlook calendar is connected to their Cal.com account

• The correct calendar(s) are toggled on for conflict checking

• External appointments that should block availability are marked Busy (not Free)

• Personal events are set to show as "Busy" with no details to protect privacy

• You've done a test booking through your own URL to confirm availability looks right

• The final URL (booking page or routing form) has been shared with your Ruby account team

What to tell Ruby

Once your Cal.com setup is live, contact your Ruby account manager and give them:

1. Your booking URL (or routing form URL)

2. A brief note on what information to collect from callers (name, email, reason for call)

3. Any business-specific instructions (e.g. "If caller mentions they're a current customer, use this URL instead")

Ruby's receptionists are trained to use web-based scheduling tools and will follow whatever instructions you provide. The simpler and more specific your instructions, the smoother the handoff.

Frequently asked questions

Does Cal.com work with Ruby out of the box?

Yes. Ruby receptionists just need a web-based booking URL they can open during a call. No special integration, no API setup, no approval process.

Can Ruby cancel or reschedule existing bookings?

Generally, no. Ruby's receptionists create new bookings, but cancellations and reschedules are outside their standard workflow. If cancellation handling matters, include a Cal.com cancellation or rescheduling link in your booking confirmation emails so clients can self-serve.

What if a rep's calendar isn't syncing correctly?

First, confirm the calendar is connected and toggled on under Settings → Calendars. Second, make sure blocking events are marked Busy. If it's still wrong, disconnect and reconnect the calendar to force a fresh sync. If the rep uses Apple Calendar or an ICS feed, switching to Google or Outlook tends to resolve it.

Can Ruby receptionists use routing forms without extra training?

Yes, with a little setup on your end. Use dropdowns with fixed options rather than free-text fields. Keep the form short (3–4 questions) and use plain language. Include a short briefing note when you share the form URL with your Ruby account manager — a clear one-paragraph explanation is usually all they need.