Todo processo envolvia um terceiro: hóspede, proprietário, portaria, fornecedor. O time podia perder horas por dia digitando mensagem, uma por uma, com o mesmo conteúdo.
Uma gestora de imóveis por temporada trocou mensagens digitadas para hóspede, proprietário e fornecedor, uma operação em parte offline e contagens de enxoval que viviam erradas por um sistema em que a reserva no PMS cria o registro, e o registro puxa check-in, limpeza, lavanderia, manutenção e repasse ao proprietário.
Este é um dos cases mais antigos do Jestor. Foi registrado em julho de 2022. O portfólio e os processos da empresa mudaram desde então. Não sabemos se o sistema descrito aqui roda sem alteração hoje. Tudo abaixo descreve a operação como era na época do case.
“A gente não tinha esse controle, e hoje a gente consegue ter em tempo real. Estou em casa, preciso saber se no escritório tem enxoval suficiente para suprir a demanda de reservas do dia, e consigo saber. Consigo tomar uma atitude para evitar o problema na experiência do hóspede: a lavanderia atrasou, ou a gente esqueceu de enviar uma faxineira. Com o Jestor a gente não tem mais esse erro.”

O que não foi trocado. O PMS continua dono da reserva e do pagamento. Os canais continuam donos do calendário. A ferramenta de formulário ficou para os dados do hóspede. Lavanderia, profissionais de limpeza e portarias continuam terceiros; o que mudou é que recebem ordem gerada em vez de mensagem digitada. Os KPIs semanais que o fundador diz não conseguir puxar automaticamente ainda entram por formulário uma vez por semana no painel.
A Be My Guest administra apartamentos e casas para locação por temporada em nome de proprietários que não têm tempo ou vontade de gerir e querem que o ativo renda. A empresa recebe o imóvel, anuncia, cuida de hóspede, limpeza, enxoval, manutenção e do repasse mensal ao proprietário. A promessa é que o proprietário não precise pensar nisso, o que significa que a empresa tem que executar toda passagem de bastão sem erro.
Locação por temporada é operação de hotel sem hotel. Cada check-out dispara limpeza, vistoria, troca de enxoval e possivelmente reparo, num prédio que a empresa não controla, com uma portaria que precisa do nome do hóspede antes. Cada check-in precisa do apartamento pronto, do enxoval entregue e do acesso liberado. O número de apartamentos multiplica tudo isso, e o calendário decide quando acontece.
Por isso o gargalo era operacional, não comercial. Reserva entrava pelo PMS e pelos canais. O que faltava à empresa era um jeito de a reserva pôr o trabalho em movimento, e um jeito de ver se o trabalho estava no prazo sem perguntar. O teste do fundador era simples: de casa, consigo saber se o escritório tem enxoval para as reservas de hoje?
“A gente não tinha esse controle, e hoje a gente consegue ter em tempo real. Estou em casa, preciso saber se no escritório tem enxoval suficiente para suprir a demanda de reservas do dia, e consigo saber. Consigo tomar uma atitude para evitar o problema na experiência do hóspede: a lavanderia atrasou, ou a gente esqueceu de enviar uma faxineira. Com o Jestor a gente não tem mais esse erro.”
Todo processo envolvia um terceiro: hóspede, proprietário, portaria, fornecedor. O time podia perder horas por dia digitando mensagem, uma por uma, com o mesmo conteúdo.
Como os processos rodavam à mão, a informação precisava ser reportada ou buscada. Se os apartamentos estavam prontos, se o enxoval dava, se a lavanderia entregaria no prazo: nada disso era visível, então planejar adiante era chute.
Limpeza, vistoria e enxoval aconteciam com pouco registrado e nada iniciando a etapa seguinte. Uma limpeza terminada não avisava ninguém que tinha terminado.
Sem processo definido para liberar um apartamento no próprio dia, a empresa não conseguia vender reserva last minute com segurança. O calendário fechava cedo para proteger a operação.
O padrão: o trabalho físico era contínuo e a informação era sob demanda. Nada estava quebrado; a empresa crescia. Mas cada apartamento a mais significava mais mensagem, mais pergunta, mais chance de esquecer uma faxineira ou errar uma contagem de toalha, e a promessa ao proprietário depende de nada disso acontecer.
| O que fazia isso antes | O que faz hoje |
|---|---|
| Extração manual de cada reserva do PMS | Um webhook cria o registro da reserva com check-in e check-out |
| Digitação de mensagem para hóspede, proprietário e fornecedor | Botões e automações mandam mensagens padrão pelo canal certo |
| Solicitação de liberação ao condomínio montada a partir dos dados do hóspede | O hóspede preenche um formulário; ele se liga à reserva; um botão envia a solicitação |
| Perguntar se o apartamento está pronto | A ordem de limpeza, aberta pela profissional no celular, carrega o formulário de vistoria; o status está no registro |
| Vistoria passada por mensagem | O formulário de vistoria é revisado pelo time interno no registro antes de o repasse ser preparado |
| Enxoval contado à mão, com frequência errado | A separação dá baixa, a ordem de coleta é gerada, a ordem de lavanderia é comparada com o que volta |
| Manutenção e reclamação tratadas caso a caso | Tickets de hóspede e proprietário, com ticket operacional aberto pelo time de atendimento para executar |
| Calendário fechado cedo para proteger a operação | Calendário aberto até 15h para reserva no mesmo dia |
O que não foi trocado. O PMS continua dono da reserva e do pagamento. Os canais continuam donos do calendário. A ferramenta de formulário ficou para os dados do hóspede. Lavanderia, profissionais de limpeza e portarias continuam terceiros; o que mudou é que recebem ordem gerada em vez de mensagem digitada. Os KPIs semanais que o fundador diz não conseguir puxar automaticamente ainda entram por formulário uma vez por semana no painel.
Reserva e pagamento continuam lá.
O registro passa por nova, confirmada, chega hoje, hospedado, saiu hoje.
A ferramenta de formulário ficou porque faz bons formulários.
A partir dos dados que o hóspede já preencheu.
A próxima pessoa não precisa ser avisada de que o apartamento está saindo.
Um formulário dentro da ordem que a profissional já abriu, e uma tela de separação tipo carrinho no tablet.
Uma pessoa revisa; o sistema move o registro adiante.
A comparação é o sistema; a contagem continua sendo uma pessoa.
Os elos difíceis são o 6 e o 8. O sistema não sabe que o apartamento está limpo nem que as toalhas voltaram; uma profissional tem que preencher o formulário e alguém tem que contar. O desenho aceita isso e faz de cada um a menor ação possível: um formulário dentro da ordem que a profissional já abriu, uma tela de separação tipo carrinho no tablet, uma comparação enviado versus devolvido que o sistema faz. Tudo que é automático na cadeia depende de esses passos de campo continuarem fáceis o bastante para serem feitos toda vez.
“A falta de software adequado gerava dor de cabeça recorrente. Não era incomum ter problema de contagem de estoque e coisas parecidas. Com o Jestor, a gente sabe que tem o número certo e não fica na mão.”
| Indicador | Resultado | De onde sai |
|---|---|---|
| Tempo em comunicação | Cerca de 15 horas por semana economizadas com automações de mensagem, pela estimativa do fundador, no início do uso | Entrevista gravada; autodeclarado, sem método |
| Reservas last minute | Um produto que não existia; hoje 5% a 10% das reservas, com calendário aberto até 15h do mesmo dia | Entrevista gravada; autodeclarado, sem período |
| Visibilidade | De perguntar ou ser avisado para ver enxoval, limpezas e check-ins em tempo real, de qualquer lugar | Entrevista gravada e case publicado |
| Precisão de enxoval | De contagens que não batiam para comparação enviado versus devolvido em toda ordem de lavanderia | Case publicado e entrevista; sem taxa de erro antes ou depois |
| Entrada de reserva | De extrair cada reserva do PMS à mão para criação automática do registro | Case publicado |
A manchete "10% a mais de receita" não é adotada como está. O case publicado diz que as reservas last minute aumentaram em 10% a receita de reservas. Na entrevista gravada, o fundador diz que last minute são 5% a 10% das reservas. Parcela das reservas não é aumento de receita, e o número do case é o teto da faixa do fundador. Este texto reporta o que o fundador disse: last minute é um produto novo viabilizado pela operação, e representa 5% a 10% das reservas.
As 15 horas são estimativa inicial do fundador. Ele dá o número como o que já era visível "no início da utilização", só com as automações de comunicação. Não há método, linha de base nem medição posterior.
"Tempo real" quer dizer registrado na hora por quem está no campo. Enxoval é tão atual quanto a última separação; status de limpeza, tão atual quanto o último formulário. O próprio fundador diz que às vezes ainda acontece erro; o que mudou é que o processo pode ser ajustado quando acontece.
Nem todo indicador é automático. O case publicado diz que os KPIs não levam tempo para calcular. Na entrevista, o fundador diz que alguns números semanais não dá para puxar automaticamente e entram por formulário. As duas coisas são verdadeiras para indicadores diferentes; a entrevista é a fonte mais específica.
Vale dizer, porque é o que normalmente aparece inflado.
Todas as descrições e as duas citações vêm do fundador, no case publicado e numa entrevista gravada. Nenhum processo foi observado ou cronometrado de forma independente.
Imóveis sob gestão, reservas por mês, custo de limpeza, taxa de perda de enxoval antes e depois, receita: nada disso aparece em nenhuma das fontes. As duas afirmações quantificadas são estimativas autodeclaradas.
O case publicado dá "10% de receita"; a entrevista dá "5% a 10% das reservas". O case diz que os KPIs são instantâneos; a entrevista diz que alguns entram por formulário semanal. Nos dois pontos este texto segue a entrevista, por ser a palavra do próprio fundador.
O case foi publicado em julho de 2022 e a entrevista é do mesmo período. O portfólio e os processos da empresa mudaram desde então. Não sabemos se o sistema descrito aqui roda sem alteração hoje.
Vários trechos foram reconstruídos pelo contexto. Onde a redação era incerta, a afirmação ficou de fora em vez de ser chutada.
Nenhuma das fontes informa quantidade de imóveis, tamanho de time ou receita. Este texto não estima.
| Indicador | Número | Fonte |
|---|---|---|
| Noites e assentos reservados na maior plataforma de temporada, 2025 | 533 milhões, alta de 8% | Airbnb, Form 10-K de 2025 |
| Valor bruto de reservas nessa plataforma, 2025 | USD 91,3 bilhões, alta de 12% | Mesmo documento |
| Região que mais cresceu em noites reservadas, 2025 | América Latina, alta de 18% em noites e 20% em valor | Mesmo documento |
| Média de noites por reserva, 2025 | 3,7 no mundo; 3,6 na América Latina | Mesmo documento |
| População adulta brasileira que aderiu ao aluguel por temporada em 2020 | 25% | Sebrae, conforme citado por imprensa regional em 2022 |
A 3,6 noites por estadia, um apartamento lotado vira mais ou menos oito vezes por mês, e cada virada é uma limpeza, uma vistoria, uma troca de enxoval e uma liberação de portaria. A carga operacional da temporada escala com reserva, não com imóvel, e é por isso que o custo de uma gestora sobe mais rápido exatamente quando a demanda está melhor.
As reservas da América Latina na maior plataforma cresceram a mais que o dobro da taxa global em 2025. Crescimento assim chega como mais viradas por semana para o mesmo time, e o processo que rodava em mensagem no volume do ano passado quebra no volume deste ano.
O relatório de uma empresa é o dado mais limpo disponível, e é usado aqui por isso. Cobre uma plataforma num mercado com várias, e nenhum de seus números descreve o custo operacional de uma gestora. O dado do Sebrae é de 2020, citado de segunda mão, e serve só como indicação de adesão. A contagem de viradas da própria gestora é o número para planejar.
A Be My Guest não carecia de software. Tinha um PMS para reserva e pagamento, e o PMS fazia o trabalho dele. O que nenhum produto de prateleira cobria era a parte depois da reserva: a limpeza, o enxoval, a portaria, o repasse, cada um feito do jeito da empresa. A pergunta que um sistema sob medida precisa responder é o que acontece no ano dois: um sistema de operação que ninguém pode mexer vira a nova planilha em três anos, com login.
Um construtor toca cada pedido do começo ao fim, com um sempre em execução.
Um novo fluxo, uma nova automação ou um novo relatório entram pelo mesmo canal, sem virar projeto novo.
Se o que foi construído não está bom, ele é refeito. Revisões ilimitadas dentro da assinatura.
Assento nunca é a régua de cobrança, o que importa quando escritório, profissionais de limpeza, vistoria e atendimento tocam os mesmos registros.
As pessoas aprendem a usar o app delas como aprendem qualquer app, abrindo. Construir, configurar e manter continua do nosso lado.
Exportação completa a qualquer momento, por CSV e API. Conformidade SOC 2, sem taxa de saída. Dá para pausar em um clique e os sistemas continuam rodando.
As descrições de antes e depois e as duas citações vêm de duas fontes: o case que o Jestor publicou em julho de 2022 e uma entrevista gravada com o fundador do mesmo período, usada pela transcrição automática. Onde as duas divergem, a entrevista prevalece. As duas são o relato do próprio fundador e não foram auditadas. A citação do fundador no case publicado sobre criar o que desenha sem código não foi usada, porque descreve um modelo de trabalho que o Jestor não oferece mais.
Modelo de negócio pelo case publicado e pelo site da própria empresa. Nenhum dado independente de porte foi encontrado.
Airbnb, Inc., Form 10-K do exercício encerrado em 31 de dezembro de 2025, arquivado na SEC. Sebrae, conforme citado pelo Bem Paraná em julho de 2022.
A manchete "10% de receita" é substituída pelo "5% a 10% das reservas" do próprio fundador. As 15 horas estão rotuladas como estimativa inicial. Nenhuma quantidade de imóveis, volume de reservas ou custo é dado, porque não existe nas fontes.