O desconto de ontem não pode virar o preço de amanhã

Quem administra apartamentos de aluguel por temporada faz a mesma conta todo dia. Quanto cobrar pela noite de amanhã, pela de sexta, pela do feriado que ainda está longe. Com cinco apartamentos dá para fazer na mão. Com trinta, não dá: ou alguém passa a manhã inteira nisso, ou os preços ficam parados e a operação perde dos dois lados, vendendo barato o que era disputado e deixando vaga a noite que teria fechado com desconto.

A saída óbvia é automatizar. E é aí que mora uma armadilha que só aparece meses depois.

O sistema que se afunda sozinho

A ideia mais natural é fazer o sistema aprender com o que aconteceu. A noite fechou a 120? Então 120 é o preço certo para aquela noite. Ajusta a base e segue.

Parece razoável e está errado, por um motivo simples: o valor que fechou é o piso da disposição a pagar, não o teto. Quem reservou a 120 talvez pagasse 150. O sistema nunca vai saber, porque ele nunca pediu 150.

Se a base passa a ser o preço de fechamento, começa uma espiral. A base nasce em 150, o sistema dá um desconto de última hora, fecha em 120, adota 120 como nova base. Na semana seguinte parte de 120, desconta de novo, fecha mais baixo, adota mais baixo. Cada rodada confirma a anterior. É profecia autorrealizável: o sistema prova que estava certo sobre um preço que ele mesmo escolheu.

Na Zelena, a operação é uma carteira de apartamentos com calendário, disponibilidade e preço diário. Testamos esse desenho antes de ligar qualquer coisa e ele se comportou exatamente assim.

Olhar como a noite fechou, nunca por quanto

A correção foi trocar o que o sistema observa.

Ele não olha mais o valor de fechamento. Olha como a noite fechou: se foi vendida sem precisar de desconto de última hora, se precisou, ou se ficou vazia. Isso é informação sobre a demanda; o valor é informação sobre a própria decisão anterior do sistema.

Uma noite que fecha sem desconto diz que havia espaço para pedir mais. Uma noite vazia diz que havia espaço para pedir menos. Um mês inteiro fechando no piso com desconto não puxa a base para baixo, porque o desconto era a ferramenta, não o diagnóstico.

Os ajustes também não são simétricos. Errar o preço para cima custa uma noite vazia, que não volta. Errar para baixo custa margem numa noite que teria vendido de qualquer jeito. São perdas de tamanhos diferentes, e o sistema sobe e desce em passos diferentes por causa disso.

Ligado, mas desligado

A parte que consideramos mais importante é a que não faz nada.

O aprendizado roda em modo observação: toda semana ele calcula o ajuste que faria e grava. Não encosta em preço nenhum. Durante semanas, o operador vê o que o sistema teria feito, ao lado do que de fato aconteceu, e julga se concorda.

Ligar é decisão humana, tomada depois de assistir. Não é botão de configuração que veio marcado de fábrica.

E mesmo depois de ligado ele opera dentro de uma cerca: a base nunca sai da faixa de mínimo e máximo que uma pessoa definiu para aquele apartamento. O sistema tem liberdade para se mover dentro do que o dono considera aceitável, e nenhuma para sair dali.

Por que isso importa fora do aluguel por temporada

O erro que descrevemos não é sobre hospedagem. É sobre qualquer sistema que aprende com um resultado que ele mesmo produziu.

Um sistema que decide a quem ligar e depois aprende com quem atendeu vai concluir que estava certo. Um que ordena a fila e aprende com quem foi atendido primeiro também. Em todos, a pergunta é a mesma: o dado que alimenta o aprendizado é sobre o mundo ou é sobre a decisão anterior do próprio sistema?

Quando é sobre a decisão anterior, ele não está aprendendo. Está se confirmando.

Se você está avaliando automatizar uma decisão que hoje é tomada por pessoa, essa é a pergunta que vale fazer antes de qualquer demonstração.