Software de agendamento para salões: funcionalidades essenciais e guia de arquitetura

A maioria dos fundadores chega ao desenvolvimento de software de agendamento para salões com uma lista de funcionalidades. Parece um briefing. Não é.

Uma lista de funcionalidades não diz nada sobre como as peças se conectam. Agendamento, escalas da equipe e pagamentos não são três telas separadas. São um único sistema que precisa estar de acordo consigo mesmo em tempo real, a cada segundo do dia.

Quando um cliente toca no horário das 2:30 PM com a Priya, quatro coisas precisam acontecer ao mesmo tempo. O horário é bloqueado, a agenda da Priya é atualizada, a pré-autorização do pagamento é processada e o painel do dono do salão mostra tudo isso. Se qualquer uma delas atrasar, você tem um agendamento duplicado e um cliente irritado na sua recepção.

O que a maioria das equipes descobre é que a diferença entre uma funcionalidade que funciona numa demo e uma que funciona num sábado à tarde com 40 atendimentos rolando não está na funcionalidade em si. Está na arquitetura por baixo dela. Este artigo detalha o que cada camada realmente exige, para que você possa conversar com um desenvolvedor e fazer as perguntas certas, ou ler um orçamento e saber se ele é completo ou raso.

A camada do cliente

É a parte que todo mundo imagina quando pensa no app. Também é a parte enganosamente fácil de especificar e surpreendentemente fácil de errar.

Cadastro, login e perfis

Criar uma conta parece um problema resolvido. Na maior parte, é. Número de telefone com OTP, ou login social, leva um ou dois dias para uma equipe competente. O que importa é o que acontece na segunda visita.

Um cliente que volta deveria ver seu profissional, seu serviço de sempre e a data do último atendimento sem digitar nada. Isso exige um cadastro de cliente ligado ao histórico de agendamentos, às formas de pagamento e a qualquer anotação que a equipe tenha feito (“alérgico a amônia”, “prefere o horário das 9 AM”).

Serviços e preços

Cada serviço precisa de um nome, uma duração, um preço e uma regra de quais profissionais podem fazê-lo, já que nem todo cabeleireiro faz balayage. Esses quatro campos determinam todo o resto. A duração define o tamanho do horário. O preço define o valor do pagamento. A regra de elegibilidade filtra quais profissionais aparecem como disponíveis. A regra de arquitetura aqui é simples: esses dados ficam em um só lugar e se atualizam em todo lugar na hora.

Escolha do profissional e disponibilidade em tempo real

Esta é a funcionalidade com mais chance de quebrar, e ela quebra em silêncio.

Para mostrar horários realmente livres, o backend precisa combinar o padrão de turnos de cada profissional com os agendamentos já existentes. Também leva em conta folgas, a duração do serviço e qualquer intervalo entre atendimentos, e calcula tudo isso ao vivo, para cada profissional, toda vez que um cliente abre a tela.

Um horário que aparece livre mas não está é o jeito mais rápido de perder um cliente para sempre. Ele agenda, recebe uma ligação do salão uma hora depois e nunca mais abre o seu app.

O motor de agenda: onde a arquitetura da maioria dos apps de agendamento para salões dá errado

Agendar, remarcar e cancelar aparecem como três itens na maioria das listas de funcionalidades. São um único sistema, e tratá-los como três é o motivo mais comum para um projeto de agendamento de salão estourar o orçamento no meio do caminho.

O motivo é este. Um agendamento é simples: encontrar um horário livre, bloquear e confirmar. Uma remarcação é um cancelamento e um agendamento executados como uma única ação atômica. Se o novo horário não for bloqueado, o antigo precisa voltar, senão seu cliente fica sem atendimento nenhum. Um cancelamento precisa liberar o horário, acionar uma decisão de reembolso com base no prazo da sua política e atualizar o dia do profissional. Ele também ajusta a previsão de receita e, se for o caso, avisa um cliente da lista de espera.

Depois vêm os casos extremos que ninguém especifica e todo mundo encontra. Dois clientes tocam no mesmo horário no mesmo segundo. Um cabeleireiro fica doente e doze atendimentos precisam ser redistribuídos ou cancelados em cascata. Um cliente remarca para um horário que só abriu porque outra pessoa está no meio de um cancelamento.

Não é um trabalho glamouroso e não impressiona numa demo. Mas é a diferença entre um app que aguenta escala e um que gera uma reclamação todo fim de semana.

Ao avaliar um orçamento, esta é a parte a investigar. Peça ao desenvolvedor que explique o que acontece quando um profissional cancela o turno com nove agendamentos marcados. A qualidade dessa resposta diz mais do que o resto da proposta.

O mesmo problema existe nos sistemas de reserva de restaurantes: o cancelamento de uma mesa pode se espalhar em cascata por todo um serviço. Nós construímos esse sistema, e a arquitetura é idêntica à que você precisa para a agenda de um salão.

Pagamentos, confirmações e notificações

Pagamentos num app de salão raramente são uma única cobrança. Normalmente é uma mistura de pagamento integral online ou um sinal para garantir o horário, junto com gorjetas e créditos de pacotes ou planos de assinatura.

Cada um deles é um fluxo diferente pelo gateway de pagamento. O sinal é o que os fundadores subestimam. Ele realmente reduz as faltas, algo bem estabelecido em negócios de serviços, mas traz uma política de reembolso que precisa ser definida antes de escrever uma linha de código. Com quanto tempo de antecedência o sinal é reembolsável? Volta para o cartão ou fica como crédito no salão? O que acontece se o salão cancelar, e quem pode passar por cima da regra?

Defina isso na fase de especificação. Encaixar lógica de reembolso num sistema de pagamento já em produção sai caro, e é uma das causas mais frequentes de aumento de escopo nesses projetos.

As notificações estão na mesma categoria de coisas subestimadas. Confirmações, lembretes 24 e 2 horas antes, alertas de cancelamento e um pedido de avaliação depois: tudo isso entra aqui. Os clientes não percebem quando elas funcionam e percebem na hora quando não funcionam. Tecnicamente, isso significa notificações push por um serviço como o Firebase, com SMS como alternativa para quem desativou o push, mais e-mail para os recibos. Três canais, três status de entrega para acompanhar e uma regra para o que acontece quando um push falha em silêncio.

O lado do negócio: administração e gestão da equipe

Um app só para clientes é metade de um produto. O que transforma isso num app de marketplace de salões de dois lados é a metade voltada para o negócio, e ela carrega pelo menos tanta lógica quanto o lado do cliente.

Gestão da equipe e das escalas

Um software de escalas para equipes de salão precisa lidar com padrões de turno que raramente são simples. Cabeleireiros de meio período que trabalham terça e sábado. Uma terapeuta que tira 90 minutos de almoço. Rodízio nos fins de semana, folgas aprovadas e uma estrutura de comissões que varia por serviço.

Cada uma dessas regras alimenta diretamente a disponibilidade que o cliente vê. Você não pode construir a tela de disponibilidade do cliente e a tela de escalas da equipe como projetos separados com uma sincronização entre eles. São duas visões de uma mesma agenda. Quando um gerente aprova um pedido de folga, os horários precisam sumir do app do cliente antes que a próxima pessoa o abra.

Painel administrativo

O painel do dono é a central de controle.

Os agendamentos do dia de todos os profissionais, o registro de clientes sem hora marcada e a criação manual de agendamentos para quem liga ficam aqui. Completam o pacote a gestão de serviços e preços, as permissões da equipe e a possibilidade de passar por cima de qualquer coisa. Esse último ponto importa mais do que parece. Salões de verdade funcionam na base da exceção: encaixar um cliente fiel, estender um atendimento, oferecer um serviço como cortesia depois de uma reclamação. Se o administrador não puder passar por cima do sistema, a equipe vai parar de usar o sistema. O requisito de arquitetura é que essas exceções sejam gravadas na mesma camada de dados dos agendamentos normais e fiquem registradas, para que seus relatórios continuem confiáveis.

Um painel que lê de uma réplica atrasada ou de um processamento noturno é um conflito de agenda esperando para acontecer. Ou são dados ao vivo, ou não é um painel.

Relatórios de atendimentos e receita

Receita por profissional, por serviço, por dia. Taxas de ocupação. Percentual de faltas, proporção de clientes recorrentes e ticket médio. São esses números que dizem ao dono se deve contratar, quais serviços promover e quem merece um aumento.

E eles dependem inteiramente do que vem antes. Um relatório só é tão preciso quanto as camadas de agenda e pagamento que o alimentam. Se os cancelamentos não estornam corretamente seus lançamentos de receita, ou se os sinais são registrados separados dos pagamentos finais, seus relatórios vão estar errados de um jeito que ninguém percebe por seis meses. Esse é o argumento mais claro de por que a arquitetura vale mais do que qualquer funcionalidade isolada de uma lista.

A stack tecnológica do seu app de salão, de forma realista

Node.js ou Laravel no backend. PostgreSQL ou MySQL como banco de dados principal, porque agendamentos são relacionais e você precisa de integridade transacional. O Redis cuida do bloqueio de horários e do cache. Stripe ou Razorpay para pagamentos, dependendo do seu mercado. Firebase para push, Twilio como alternativa por SMS.

Nada disso é exótico, e a ideia é essa. Escolhas incomuns cobram o preço depois, quando você precisa contratar ou passar o projeto adiante. O que importa é que a stack suporte transações reais e atualizações em tempo real, as duas coisas das quais um app de agendamento para salões depende. A escala também pesa, então decida desde o primeiro dia para qual das três você está construindo. Deixar múltiplas unidades para depois significa reescrever o seu modelo de dados.

App de agendamento para salões sob medida ou template: como decidir

Um script de template reúne essas funcionalidades como módulos fixos e genéricos. Para testar se as pessoas da sua região vão mesmo agendar online, é uma forma razoável de descobrir gastando pouco. Não vamos fingir o contrário.

Ele passa a limitar no momento em que o seu negócio precisa de algo específico. Comissões que variam conforme a senioridade do profissional. Um modelo de assinatura com créditos mensais. Profissionais que circulam entre várias unidades, ou uma regra de sinal diferente para cada serviço. Num template, cada uma dessas coisas é impossível ou uma modificação cara num código que não é seu e que você não consegue auditar por completo.

A objeção honesta ao desenvolvimento sob medida é o custo e a incerteza. O custo de desenvolver um app para salões num contrato por hora sem limite pode mesmo sair do controle. É por isso que não trabalhamos assim. Combinamos um preço fechado e uma data de lançamento fixa antes de começar, com a primeira versão a partir de $8,000, dependendo do escopo. Em mais de 18 anos e mais de 1000 empresas atendidas, vimos que a disciplina de definir bem o escopo desde o início é o que mantém os dois números honestos.

Preço fechado e data de lançamento fixa para o seu app de salão

Conte para nós do que o seu salão, spa ou clínica realmente precisa. Quantas unidades você tem, como a sua equipe é remunerada e qual é a sua política de cancelamento: tudo isso entra no escopo, com base na arquitetura descrita acima.

Peça um orçamento. Preço fechado combinado antes de começarmos.

Arun Andiselvam

LinkedIn

Sou um empreendedor que já criou cinco marcas. Vendi a primeira, uma ferramenta de SEO, num negócio de seis dígitos, e hoje lidero a Appkodes, criando apps móveis e web sob medida para fundadores e empresas. Financiei cada uma delas por conta própria desde o primeiro dia.