Voltar ao blog Business software

Como escolher um software de agendamento de consultas autoalojado: teste todo o processo de marcação

Compare soluções de agendamento simulando marcações realistas, desde a consulta de disponibilidade até às alterações, notificações e revisão dos dados — em vez de contar funcionalidades.

Responsável pelas operações a testar uma marcação de consulta, desde a consulta de disponibilidade até à confirmação e alteração do horário

Comece pelos processos de marcação de que a sua equipa realmente precisa

Uma lista de funcionalidades não permite saber se uma solução de agendamento se adapta à forma como o seu serviço é prestado. Comece com marcações representativas: uma consulta de rotina, um serviço mais demorado, uma marcação próxima da hora de início, um cancelamento e uma alteração que afete a disponibilidade dos funcionários.

Antes de testar um produto, anote o resultado esperado para cada cenário: quem pode fazer a marcação, que funcionário deve recebê-la, que informações o cliente tem de fornecer e o que a equipa tem de fazer depois. Isto torna as comparações mais consistentes e revela requisitos que uma lista genérica pode não incluir.

Consulte a documentação oficial e atual do produto e da versão em avaliação. O [repositório do Easy!Appointments](https://github.com/alextselegidis/easyappointments), por exemplo, descreve-o como um sistema de agendamento de código aberto que permite aos utilizadores controlar o seu processo de marcação. Essa descrição geral não esclarece como funciona cada etapa.

  • Enumere os tipos de consulta, as funções dos funcionários, os dados dos clientes e os horários de funcionamento relevantes.
  • Inclua exceções: pedidos sobrepostos, ausência de um funcionário, cancelamento tardio e marcação fora do horário normal.
  • Para cada cenário, defina o que conta como aprovação, reprovação ou solução manual aceitável.
Comece pelos processos de marcação de que a sua equipa realmente precisa

Teste as regras de disponibilidade, incluindo os casos-limite

A disponibilidade é mais do que um horário semanal. Verifique as regras que determinam se um horário pode ser disponibilizado: duração da consulta, tempo de preparação ou limpeza, antecedência mínima, até quando os clientes podem marcar e eventuais limites de consultas por dia ou período. Os controlos variam consoante o produto.

Teste os casos-limite: um horário imediatamente dentro e fora da antecedência mínima, uma marcação que terminaria à hora de fecho e duas consultas separadas exatamente pelo intervalo necessário. Compare as opções apresentadas ao cliente com as que aparecem na vista dos funcionários.

Registe o valor configurado, a tentativa de marcação e o resultado. Não conclua que uma regra é suportada apenas com base no nome de uma opção nas definições.

  • É possível definir a duração necessária para cada serviço ou tipo de consulta?
  • O sistema mantém o intervalo necessário antes ou depois de uma consulta?
  • Os períodos de marcação e os limites diários ou semanais são claros e testáveis?
  • O que acontece quando a disponibilidade dos funcionários muda depois de um horário ser apresentado?
Teste as regras de disponibilidade, incluindo os casos-limite

Verifique os conflitos de calendário e identifique que sistema controla cada decisão

Uma aplicação de agendamento e um calendário ligado podem influenciar a disponibilidade, mas a interação entre ambos varia consoante o produto e a configuração. Verifique se a aplicação consulta eventos do calendário, regista as marcações aceites, atualiza alterações e assinala conflitos.

Faça um teste repetível: crie um evento diretamente no calendário ligado e veja se o horário fica indisponível para um novo cliente. Depois, marque através do sistema de agendamento e confirme o que aparece no calendário. Por fim, altere ou elimine o evento e observe se, e quando, a página de marcações é atualizada.

Considere também o que acontece se a sincronização sofrer atrasos, for interrompida ou ficar indisponível. Registe se o sistema impede o conflito, apresenta um aviso ou deixa a resolução a cargo dos funcionários.

  • Teste o cenário com o calendário de um funcionário e com todos os calendários de que o processo depende.
  • Verifique fusos horários, eventos recorrentes e alterações feitas depois de um cliente ter marcado.
  • Defina como os funcionários vão detetar e resolver conflitos que a aplicação não impeça automaticamente.

Percorra as alterações, os cancelamentos e as passagens entre funcionários

O percurso continua depois da confirmação inicial. Teste um cancelamento e uma alteração feitos pelo cliente, uma alteração iniciada por um funcionário e uma consulta que tenha de ser atribuída a outra pessoa. Verifique se o horário original volta a ficar disponível e se o novo horário aparece de forma consistente na aplicação e nos sistemas ligados.

Inclua uma passagem de responsabilidade entre funcionários. Confirme quem pode fazer a alteração, como é atualizada a pessoa responsável e que informações ficam visíveis para o funcionário seguinte. Se o processo exigir um telefonema ou uma alteração manual no calendário, registe-o como procedimento operacional.

Consulte a documentação atual para conhecer as permissões e os processos de alteração descritos para o produto. Confirme os passos num ambiente de teste.

  • Teste separadamente as permissões de alteração dos clientes, dos funcionários da receção e dos administradores.
  • Verifique se o cliente e os funcionários afetados recebem um registo atualizado depois de uma alteração.
  • Defina como a equipa tratará pedidos que não possam ser concluídos através da interface de marcação.

Verifique as confirmações e os lembretes, incluindo falhas de entrega

Uma confirmação apresentada no ecrã não é o mesmo que um email entregue. Teste que mensagem é gerada, que endereço ou serviço a envia e como a equipa consegue perceber se a entrega falhou. As notificações, as novas tentativas e os relatórios de falhas variam consoante o sistema e a configuração de email.

Faça testes separados para uma marcação bem-sucedida, uma alteração de horário e um cancelamento. Verifique o conteúdo, o destinatário, o momento do envio e a exatidão dos dados da consulta. Em seguida, teste uma falha de entrega controlada, usando um método aprovado para o ambiente de teste. Registe se há erro, nova tentativa ou acompanhamento manual.

Confirme que definições pertencem à aplicação e quais dependem do serviço de email. Designe uma pessoa responsável por monitorizar a entrega e tratar dos pedidos dos clientes quando uma mensagem esperada não chega.

  • Verifique se o momento das confirmações e dos lembretes corresponde à hora da consulta e à política da equipa.
  • Confirme que alterações e cancelamentos não deixam os clientes com mensagens desatualizadas.
  • Documente o procedimento alternativo para emails que falhem ou não cheguem.

Analise os acessos e as decisões relativas aos dados dos clientes

O autoalojamento não elimina as decisões relativas aos dados e aos acessos. Identifique que informações sobre clientes e consultas são armazenadas, que funções podem consultá-las ou alterá-las e se alguma informação é enviada para calendários ligados, serviços de email ou outras integrações. As práticas e os controlos variam; verifique-os na documentação e na configuração do produto.

Utilize dados de exemplo durante a avaliação. Teste cada função com o nível mínimo de acesso necessário e verifique o que acontece quando um funcionário muda de responsabilidades ou sai da organização. Decida quem pode administrar o serviço e como serão tratados os pedidos de conservação e eliminação de dados, de acordo com as políticas e obrigações aplicáveis à organização.

Pergunte onde os dados relevantes são tratados e armazenados, que controlos estão disponíveis e o que está incluído nas cópias de segurança. Baseie as decisões em respostas documentadas e nos requisitos da organização, não apenas na expressão «autoalojado».

  • Faça o inventário dos campos dos clientes, dos detalhes das consultas, dos serviços ligados e das funções dos funcionários.
  • Teste os acessos com contas separadas, em vez de se basear apenas na perspetiva de um administrador.
  • Registe as responsabilidades relativas à conservação, eliminação, cópias de segurança e remoção de contas quando alguém sai da organização.

Faça um pequeno projeto-piloto com critérios de aprovação ou reprovação por escrito

Um projeto-piloto focado é mais esclarecedor do que uma demonstração abrangente. Escolha alguns funcionários, um conjunto limitado de tipos de consulta e marcações de exemplo realistas. Use os mesmos casos de teste entre produtos para que diferenças de configuração ou de expectativas não distorçam a comparação.

Para cada caso, registe a configuração, os passos, o resultado esperado, o resultado observado e a fonte de evidência. Consulte a documentação atual para confirmar se um comportamento é descrito como suportado e, em seguida, teste-o na prática. Se a documentação e o resultado observado não coincidirem, peça esclarecimentos ao fornecedor ou aos responsáveis pelo projeto.

Defina os limiares antes de iniciar o projeto-piloto. Alguns requisitos podem ser obrigatórios; outros podem ser aceitáveis com um procedimento documentado para os funcionários. Não atribua a uma solução manual o mesmo valor de um controlo automático, a menos que a equipa tenha concordado em assumir esse trabalho adicional.

  • Crie uma folha de teste com o cenário, o resultado esperado e observado, as evidências e a pessoa responsável.
  • Inclua, no mínimo, uma marcação normal, um caso-limite, um conflito de calendário, uma alteração e uma falha de notificação.
  • Classifique os requisitos como obrigatórios, aceitáveis com uma solução alternativa ou não necessários.
  • Repita os cenários críticos após alterações à configuração ou atualizações.

Escolha o modelo de implementação adequado à sua capacidade operacional

O autoalojamento pode ser adequado a uma equipa que pretenda gerir o ambiente da aplicação e tenha responsabilidades claramente atribuídas pelos dados, pelos acessos e pelas operações contínuas do serviço. Não é automaticamente a escolha certa para todas as organizações. Compare os modelos de implementação com os seus requisitos e confirme que responsabilidades operacionais cabem à sua equipa.

Identifique quem vai gerir o ambiente da aplicação, monitorizar as integrações, manter as políticas de acesso, rever as cópias de segurança e responder a falhas no processo de marcação ou de notificação. Se a organização não puder atribuir estas responsabilidades, compare outros modelos e confirme que trabalho operacional continua a caber à equipa.

A infraestrutura gerida pode reduzir parte do trabalho de alojamento sem retirar ao cliente as decisões de governação. A Airbip disponibiliza implementação gerida para aplicações do seu catálogo público. As instâncias são executadas como cargas de trabalho Docker em servidores cloud da Airbip; a Airbip automatiza o encaminhamento e os certificados TLS através do Traefik e do Let’s Encrypt, disponibiliza verificações de DNS e gestão do ciclo de vida do serviço, e oferece cópias de segurança diárias, semanais e mensais configuráveis. Os clientes podem utilizar um subdomínio da Airbip ou um domínio personalizado compatível. Estas capacidades de infraestrutura não comprovam o comportamento do sistema de agendamento em matéria de marcações, calendários, email ou governação de dados, nem eliminam a necessidade de tomar decisões sobre acessos e dados. Consulte as condições atuais da Airbip no respetivo site.

  • Escolha o autoalojamento apenas se houver uma pessoa responsável pelo trabalho operacional e de governação exigido pelos seus requisitos.
  • Separe o comportamento da aplicação das dependências de alojamento, calendário, email e processos dos funcionários.
  • Compare os modelos de implementação com os mesmos cenários de marcação e critérios escritos de aprovação ou reprovação.

Perguntas frequentes

O que devo testar primeiro ao comparar software de agendamento de consultas autoalojado?

Comece pelas marcações mais frequentes e acrescente casos-limite: um pedido com pouca antecedência, um horário que exige um intervalo, um conflito de calendário, uma alteração e uma falha no email de confirmação. Defina o resultado esperado antes de testar.

O autoalojamento garante que os dados das consultas permanecem privados?

Não. Verifique que dados a aplicação armazena, quem pode aceder-lhes e que informações podem ser transmitidas a calendários ligados, serviços de email ou outras integrações. Tenha também em conta as políticas de acesso e governação da sua organização.

Como posso testar o tratamento de conflitos de calendário?

Crie um evento diretamente no calendário ligado, tente marcar o mesmo horário através do sistema e, em seguida, altere ou elimine o evento. Registe se o horário fica bloqueado, se as alterações aparecem nos dois sistemas e o que acontece quando a sincronização sofre atrasos.

O alojamento gerido é o mesmo que um processo de agendamento gerido?

Não. A infraestrutura gerida pode tratar de tarefas de alojamento, mas não comprova, por si só, as regras de agendamento, o comportamento dos calendários, a entrega de emails nem os procedimentos da sua equipa. Avalie esses aspetos separadamente.

Quando poderá ser mais adequado escolher outro modelo de implementação?

Considere alternativas se a equipa não puder atribuir responsáveis pelas tarefas operacionais e pelas responsabilidades relativas aos acessos e aos dados exigidas pelo autoalojamento. Compare os modelos com os requisitos reais da organização.

Fontes e leituras adicionais

  1. Easy!Appointments repository — GitHub
  2. Docker documentation — Docker
  3. Traefik documentation — Traefik Labs
  4. Let’s Encrypt documentation — Internet Security Research Group