Como ligar a Ruby Receptionists ao Cal.com (e deixar de te preocupar com reservas duplicadas)
Os rececionistas em direto da Ruby podem marcar compromissos diretamente no teu calendário Cal.com, o que significa que não há scheduling links partilhados com clientes, não há troca de mensagens para trás e para a frente, nem duplicados. Aqui está como o configurar corretamente.

On this page
- Como a Ruby + Cal.com funciona na prática
- Passo 1: Criar uma Team
- Passo 2: Convidar os membros da tua team
- Passo 3: Criar um Scheduling link de equipa com Round Robin
- Passo 4: Definir rankings de prioridade para cada host
- Passo 5: Copiar o URL de reserva da tua team e dar-lho à Ruby
- Como construir o formulário de routing
- Configurar as regras de routing
- Como fica para a Ruby
- Lista de verificação rápida antes de entrares em produção
- O que dizer à Ruby
- Perguntas frequentes
- O Cal.com funciona com a Ruby logo à partida?
- A Ruby pode cancelar ou reagendar reservas existentes?
- E se o calendário de um representante não estiver a sincronizar corretamente?
- Os rececionistas da Ruby podem usar formulários de routing sem formação extra?
Se usas a Ruby Receptionists para tratar chamadas recebidas, já sabes o valor de ter uma pessoa real a atender o telefone. Mas há um momento em quase todas as chamadas da Ruby em que as coisas podem ficar estranhas: quem liga quer marcar um compromisso, e o teu rececionista tem de perceber quando estás realmente livre.
É exatamente esse o problema que o Cal.com resolve. Dá à Ruby um único URL de reserva, e os rececionistas deles podem ver a tua disponibilidade em tempo real, preencher os dados de quem ligou e confirmar o compromisso, tudo enquanto continuam ao telefone. Quem liga nunca tem de ver um scheduling link. Só lhe dizem que ficou marcado (e recebe lembretes da Cal, para não se esquecer da reunião).
Este guia mostra-te como a integração funciona e cobre as duas configurações mais comuns que vemos: round robin de equipa com encaminhamento por prioridade (quando tens vários representantes e queres que o melhor tenha a primeira oportunidade), e encaminhamento baseado em formulários (quando precisas de enviar quem liga para a pessoa certa com base no que diz na chamada).
Como a Ruby + Cal.com funciona na prática
Os rececionistas da Ruby são treinados para usar ferramentas de agendamento na web durante as chamadas. Na prática, funciona de forma simples:
1. Quem liga entra — Rececionista da Ruby atende
2. O rececionista abre o teu link do Cal — Vê disponibilidade em tempo real
3. Preenche a reserva — Nome, email, motivo de quem liga
4. Compromisso confirmado — Os teus representantes e o teu cliente recebem a notificação
O rececionista está, essencialmente, a fazer de intermediário humano entre quem liga e a tua página de reserva do Cal.com. Recolhe a informação, navega no fluxo de reserva e submete-o. Ficas com um compromisso confirmado no teu calendário, e quem liga tem uma experiência humana em que confia.
Aqui vai a versão do mundo real: um empreiteiro de serviços domésticos estava a receber uma avalanche de chamadas recebidas. Contratou a Ruby para lidar com o excesso e precisava que o rececionista da Ruby marcasse chamadas diretamente com a equipa de vendas. Mas não queria que a Ruby partilhasse quatro links de calendário pessoais diferentes — queria um único URL, distribuição inteligente e zero reservas duplicadas.
A resposta é um Team Event com Round Robin + Priority no Cal.com.
Passo 1: Criar uma Team
No Cal.com, vai a Teams na barra lateral esquerda e cria uma nova team. Dá-lhe um nome como "Sales Team" ou "Service Scheduling." A função Teams no Cal permite-te gerir reservas para um grupo de pessoas.

Passo 2: Convidar os membros da tua team
Nas definições da tua team, convida cada membro por email.

Este passo é crítico — cada pessoa tem de aceitar o convite por email antes de aparecer como host disponível. Assim que aceitarem, também precisam de ligar o respetivo calendário à conta Cal.com.
Lista de verificação dos membros da team: Cada membro precisa de: (1) aceitar o convite da team, (2) ligar o respetivo calendário ao Cal.com e (3) ativar esse calendário para verificação de conflitos. Os três passos, para cada pessoa.
Passo 3: Criar um Scheduling link de equipa com Round Robin
Dentro da tua team, cria um novo Scheduling link.
Encontras a tua área de reserva da team à direita da tua área de reserva pessoal no Cal.

Ao selecionar o tipo de agendamento, escolhe Round Robin. Isto distribui as reservas pelos membros disponíveis da team automaticamente.

Passo 4: Definir rankings de prioridade para cada host
Na secção de atribuição da reserva do evento, faz scroll até "Round-robin hosts" e atribui um nível de prioridade a cada pessoa. O Cal.com tenta sempre marcar primeiro com o representante disponível de maior prioridade. Se essa pessoa estiver ocupada, passa para o nível de prioridade seguinte. Só quando todos os níveis de prioridade mais altos estiverem indisponíveis é que desce a cascata.


Passo 5: Copiar o URL de reserva da tua team e dar-lho à Ruby
Depois de publicado, vais ter um único URL de reserva como cal.com/team/[your-team]/[event-name]. Dá isto ao teu account manager da Ruby. Quando entra uma chamada, o rececionista abre-o, vê a disponibilidade em tempo real de toda a tua team (com prioridade aplicada automaticamente) e marca o horário.Cenário 2: Encaminhar quem liga para a pessoa certa com base no que diz
Às vezes podes querer um controlo mais granular sobre quem é marcado. Podes precisar de encaminhar quem liga para um representante específico pelo nome, para um especialista de produto ou para a equipa regional certa.
É para isso que o Cal.com Routing Forms foi criado. Em vez de dares à Ruby um link de reserva direto, dás-lhes um URL de formulário. O rececionista preenche as respostas com base na chamada, e o formulário encaminha automaticamente para a página de reserva certa.
Como construir o formulário de routing
Vai a Routing Forms na tua barra lateral do Cal.com e cria um novo formulário.

Adiciona as perguntas às quais o teu rececionista vai responder em nome de quem liga. Por exemplo:
-
"O cliente pediu um membro específico da team?" (Dropdown — encaminha para o representante indicado)
-
"Que produto ou serviço foi mencionado pelo cliente?" (Dropdown — encaminha para o especialista)
-
"Em que cidade ou região está o cliente?" (Dropdown — encaminha para a equipa regional)
-
"Nome de quem liga" (Texto — passado para a confirmação da reserva)
-
"Email ou telefone de quem liga" (Texto — passado para a confirmação da reserva)
Configurar as regras de routing
1. Adiciona uma regra para cada representante nomeado — "Se [membro da team] for igual a [Nome]" → encaminha para o scheduling link dessa pessoa.
2. Adiciona uma regra para cada produto ou serviço — "Se [produto] for igual a [Nome do Produto]" → encaminha para a página de reserva do especialista.
3. Adiciona uma regra para cada região — "Se [cidade/região] for igual a [Região]" → encaminha para o event da team regional correta.
4. Adiciona um fallback padrão — Define sempre um caminho padrão para quando nenhuma condição corresponder — normalmente o teu event principal de round robin da team.
Como fica para a Ruby
O rececionista abre o URL do formulário de routing, responde às perguntas com base na chamada e submete. O Cal.com trata do routing — o rececionista é levado diretamente para a página de reserva certa.
Dica profissional: Usa campos dropdown em vez de texto livre sempre que possível. Isso facilita a seleção rápida pelos rececionistas e evita erros de routing causados por gralhas.
Copia o URL publicado do formulário de routing e fornece-o à Ruby. O teu URL vai parecer-se com: cal.com/forms/[your-form-id]
Lista de verificação rápida antes de entrares em produção
-
Cada membro da team aceitou o convite da team do Cal.com
-
O Google Calendar ou Outlook de cada pessoa está ligado à respetiva conta Cal.com
-
O(s) calendário(s) correto(s) estão ativados para verificação de conflitos
-
Compromissos externos que devem bloquear a disponibilidade estão marcados como Busy (não Free)
-
Os eventos pessoais estão definidos para aparecer como "Busy" sem detalhes para proteger a privacidade
-
Fizeste uma reserva de teste através do teu próprio URL para confirmar que a disponibilidade parece correta
-
O URL final (página de reserva ou formulário de routing) foi partilhado com a tua equipa de conta Ruby
O que dizer à Ruby
Assim que a tua configuração do Cal.com estiver ativa, contacta o teu account manager da Ruby e dá-lhes:
-
O teu URL de reserva (ou URL do formulário de routing)
-
Uma nota breve sobre que informação deves recolher de quem liga (nome, email, motivo da chamada)
-
Quaisquer instruções específicas do negócio (ex.: "Se quem liga disser que é um cliente atual, usa este URL em vez deste")
Os rececionistas da Ruby são treinados para usar ferramentas de agendamento na web e vão seguir quaisquer instruções que lhes deres. Quanto mais simples e específicas forem as tuas instruções, mais suave será a transição.
Perguntas frequentes
O Cal.com funciona com a Ruby logo à partida?
Sim. Os rececionistas da Ruby só precisam de um URL de reserva na web que possam abrir durante a chamada. Sem integração especial, sem configuração de API, sem processo de aprovação.
A Ruby pode cancelar ou reagendar reservas existentes?
Geralmente, não. Os rececionistas da Ruby criam novas reservas, mas cancelamentos e reagendamentos ficam fora do fluxo de trabalho standard. Se o tratamento de cancelamentos for importante, inclui um link de cancelamento ou reagendamento do Cal.com nos teus emails de confirmação de reserva para que os clientes o possam fazer por conta própria.
E se o calendário de um representante não estiver a sincronizar corretamente?
Primeiro, confirma se o calendário está ligado e ativado em Definições → Calendars. Segundo, certifica-te de que os eventos de bloqueio estão marcados como Busy. Se continuar errado, desliga e volta a ligar o calendário para forçar uma sincronização nova. Se o representante usar Apple Calendar ou um feed ICS, mudar para Google ou Outlook costuma resolver o problema.
Os rececionistas da Ruby podem usar formulários de routing sem formação extra?
Sim, com um pouco de preparação da tua parte. Usa dropdowns com opções fixas em vez de campos de texto livre. Mantém o formulário curto (3–4 perguntas) e usa linguagem simples. Inclui uma nota de briefing curta quando partilhares o URL do formulário com o teu account manager da Ruby — uma explicação clara de um parágrafo costuma ser tudo o que precisam.
