Multiunidade: o que muda no sistema de gestão
Muito sistema de coworking anuncia suporte a multiunidade e entrega apenas um campo "unidade" no cadastro. Na prática, operar duas unidades exige decisões de arquitetura que aparecem em seis lugares, e migrar depois de abrir custa bem mais que escolher antes.
O que precisa ser comum
Um cadastro por pessoa. Se o membro precisa se cadastrar de novo para usar a outra unidade, ele não vai usar, e você perdeu o principal argumento de ter duas.
Um saldo de créditos, válido nas duas. É o benefício mais concreto da rede e custa pouco, porque o cliente continua sendo um só consumindo uma vez.
Uma política de reserva. Antecedência, cancelamento, no-show e limites idênticos. Regra diferente por unidade é ingovernável: a equipe não memoriza e o cliente não entende.
Uma fatura. Somando o uso de todas as unidades. Cliente com dois boletos acha que tem dois fornecedores.
O que precisa ser local
Disponibilidade e agenda, por endereço.
Tabela de preço, se as unidades tiverem padrões diferentes. Só deixe a diferença visível antes da reserva, nunca na fatura.
Calendário operacional. Feriado municipal, manutenção, horário de funcionamento.
Estoque físico. Projetor, cabo, flip chart. Agenda que promete o que não existe naquele endereço gera o pior tipo de frustração.
Equipe e permissões. A recepção da unidade A não precisa (e em geral não deve) editar reservas da unidade B.
Os seis testes para fazer na demonstração
1. Cadastro único. Crie um membro na unidade A e tente reservar na B. Deve funcionar sem novo cadastro.
2. Saldo compartilhado. Dê 4 créditos, consuma 2 na unidade A e verifique se restam 2 na B.
3. Busca pela unidade primeiro. A tela de reserva deve começar perguntando a unidade, não listando todas as salas de todos os endereços juntas. Sala com nome "Sala Azul" em dois lugares diferentes é confusão garantida.
4. Relatório separado. Extraia utilização por unidade. Se só sair a média consolidada, o relatório é inútil para decisão: uma unidade a 80% e outra a 30% dão 55%, que não descreve nenhuma das duas.
5. Permissão por unidade. Entre como recepcionista da unidade A e tente editar uma reserva da B.
6. Fatura consolidada. Gere a fatura de um membro que usou as duas e veja se sai uma só.
Se o sistema falhar nos testes 1, 2 ou 4, ele não é multiunidade, é monousuário com um campo a mais.
Rateio de receita entre unidades
Se as unidades têm sócios ou centros de custo diferentes, defina isso antes de acontecer.
O modelo mais simples e que evita discussão: a receita fica com a unidade que prestou o serviço, não com a que vendeu o contrato. Quem entregou a sala pagou a limpeza, a energia e a equipe.
O sistema precisa conseguir separar isso no relatório. Se ele só mostra a receita total, você vai fazer esse rateio na mão todo mês.
Desequilíbrio grande e persistente entre unidades é informação, não problema contábil: uma delas está com sala escassa ou com preço desalinhado.
A pergunta de custo
Sistemas cobram multiunidade de formas bem diferentes:
| Modelo | Efeito ao crescer |
|---|---|
| Preço fixo por unidade | Previsível, o mais comum |
| Preço por membro, somando todas | Cresce junto com a base |
| Plano multiunidade com teto | Bom até o teto, salto na virada |
Pergunte também se a segunda unidade tem custo de implantação e se o subdomínio próprio vale para as duas, ponto tratado em sistema com subdomínio próprio.
Se você ainda tem uma unidade
Vale escolher pensando na segunda? Depende de quão real ela é.
Se a expansão é hipótese distante, não pague hoje por recurso que talvez nunca use. Mas confirme uma coisa só: que os seus dados saem. Com exportação garantida, trocar de sistema na hora da expansão é caro mas possível. Sem ela, é refazer tudo.
Os números que dizem se chegou a hora de abrir a segunda unidade estão em métricas de coworking, e a organização da agenda entre endereços em agenda compartilhada entre unidades.
