A integração não é um projeto de tecnologia. É o trabalho de transformar uma reserva num quarto pronto sem um telefonema, uma mensagem de hóspede numa tarefa com um responsável e uma avaria numa reparação com um prazo definido. Mantido num âmbito restrito, esse trabalho cabe em 30 dias em qualquer PMS com uma API documentada, e o plano abaixo apresenta a sequência, os responsáveis e as verificações.

A quem se destina este plano

• Responsáveis de sistemas e gestores de TI que precisam de um âmbito e cronograma defensáveis

• Diretores de operações e diretores-gerais que procuram valor antes da época alta

• Responsáveis de housekeeping e manutenção que pretendem estados fiáveis e menos chamadas telefónicas

Pressupõe um PMS na cloud com acesso por API, como Mews, Apaleo, Oracle OPERA Cloud, Cloudbeds ou Guestline, e um único hotel ou um hotel de um grupo utilizado como piloto.

O que tem de estar garantido antes do primeiro dia?

Quatro coisas, e se alguma faltar, a contagem ainda não começou.

1. O acesso à API é concedido, não apenas prometido. Responsável: responsável pelo sistema ou gestor de TI. Duração: reserve de uma a duas semanas antes do primeiro dia, pois este é o passo que os fornecedores costumam atrasar. Necessita de credenciais, dos limites de pedidos documentados (rate limits) e, quando disponibilizado, de um ambiente de testes (sandbox). A Mews publica os seus endpoints na documentação da API Mews Connector e a Apaleo publica os seus em apaleo.dev, para que possa analisar as restrições antes de se comprometer com um âmbito.

2. Um patrocinador executivo nomeado. Responsável: diretor-geral. Duração: uma conversa. Alguém tem de ter a autoridade para dizer não ao desvio de âmbito (scope creep) na terceira semana.

3. Uma base de referência por escrito. Responsável: governanta-geral e responsável de receção. Duração: meio dia. Registe o tempo médio atual de disponibilização de quartos, a taxa de conclusão no prazo e as chamadas por turno entre a receção e o housekeeping. Sem isto, não conseguirá provar que o projeto funcionou.

4. Um perímetro de piloto. Responsável: governanta-geral / gestor de housekeeping. Duração: uma hora. Um piso, um turno, um supervisor.

A integração deve ser unidirecional ou bidirecional?

Escolha o modelo que melhor se alinha com o seu fornecedor e o seu nível de tolerância ao risco, e comece pelo mais simples.

Comece de forma unidirecional se tiver dúvidas. Adicione a sincronização bidirecional no segundo mês, assim que a equipa confiar no que vê. A Sweeply suporta ambos os padrões nas suas mais de 20 integrações de PMS, pelo que a decisão depende da sua operação e não do conector.

O plano de 30 dias: oito passos com responsável e duração

1. Alinhar os casos de uso e congelar o âmbito. Responsável: patrocinador executivo. Duração: dias 1 a 2. Quatro casos de uso são o número ideal para um primeiro lançamento: sincronização de estados de quartos, criação de tarefas de limpeza a partir de checkouts, pedidos de hóspedes convertidos em tarefas e reencaminhamentos para manutenção. Tudo o resto vai para uma lista marcada como "fase dois".

2. Definir estados em linguagem clara. Responsável: governanta-geral, em conjunto com o responsável de receção. Duração: dias 3 a 5. Descreva o que significam realmente no seu hotel os estados limpo, sujo, em curso, inspecionado, pronto, fora de serviço (out of order) e indisponível (out of service), bem como que transições são permitidas. A maior parte das falhas de integração deve-se à inexistência desta meia página.

3. Mapear quartos, tipos de quartos e pisos. Responsável: responsável pelo sistema. Duração: dias 6 a 8. Crie uma tabela de referência canónica e mantenha-a sob controlo de versões. Qualquer discrepância futura será diagnosticada face a esta tabela.

4. Configurar tipos de tarefas, prioridades e tempos de resposta. Responsável: responsáveis de housekeeping e de manutenção em conjunto. Duração: dias 9 a 12. Associe categorias de pedidos de hóspedes a tipos de tarefas, defina prazos de execução e decida para quem são escaladas as tarefas em atraso. Os módulos de housekeeping e manutenção da Sweeply são configurados neste passo.

5. Definir funções, acessos e minimização de dados. Responsável: responsável pelo sistema, com o encarregado da proteção de dados. Duração: dias 13 a 15. Extraia apenas os campos que o trabalho exige, restrinja os dados dos hóspedes às funções que deles necessitam e ative os registos de auditoria. Os termos de alojamento, encriptação e tratamento de dados da Sweeply estão publicados na página de confiança, caso o departamento de compras os solicite.

6. Fazer um piloto num piso e num turno. Responsável: gestor de housekeeping. Duração: dias 16 a 20, decorrendo de três a cinco dias em ambiente real. Acompanhe os turnos no terreno em vez de ler relatórios. Registe todas as falhas de mapeamento e todos os momentos em que um colaborador hesite.

7. Corrigir e, em seguida, realizar a avaliação de decisão (go/no-go). Responsável: patrocinador executivo. Duração: dias 21 a 24. Compare o tempo de disponibilização de quartos e a conclusão dentro do prazo obtidos no piloto com a base de referência definida antes do dia um. Se os indicadores não tiverem melhorado, descubra o motivo antes de alargar o problema.

8. Fasear a implementação e estabilizar. Responsável: diretor-geral, com um responsável por departamento. Duração: dias 25 a 30, mais duas semanas de verificações diárias. Implemente piso a piso ou edifício a edifício, verifique a integridade da API e as tarefas em atraso todas as manhãs e mantenha um registo visível de incidentes para consolidar a confiança.

Existem dois casos de implementação publicados que vale a pena consultar a par deste plano. A STAYERY transitou de folhas de cálculo para o agendamento automatizado das limpezas durante a estadia no Apaleo (caso de estudo STAYERY), e o Volkshotel Amsterdam manteve 196 quartos e uma equipa de 33 nacionalidades em pleno funcionamento durante uma migração da Mews (caso de estudo Volkshotel).

Que dados têm efetivamente de coincidir?

Quatro objetos concentram praticamente todo o risco. Defina os respetivos campos antes de iniciar qualquer configuração.

Registe as transições de estado permitidas como uma sequência (por exemplo: sujo, em curso, limpo, inspecionado, pronto) e mantenha-as simples. Cada estado adicional é um estado sobre o qual alguém terá de receber formação.

Como saber se está a funcionar?

Acompanhe cinco métricas semanalmente durante os dois primeiros meses e, depois, mensalmente:

• Percentagem de quartos atribuídos automaticamente em vez de manualmente

• Tempo médio de disponibilização dos quartos face à base de referência pré-integração

• Taxa de conclusão no prazo para pedidos de hóspedes e ordens de trabalho de manutenção

• Taxa de erros de API e latência média

• Chamadas por turno entre a receção e o housekeeping

A última métrica é a que o pessoal sente primeiro. Entre os clientes da Sweeply, o tempo de coordenação costuma diminuir cerca de 20%, e é essa a capacidade que o projeto realmente recupera.

O que costuma falhar e como resolver rapidamente?

Três problemas representam a maioria dos pedidos de suporte. As divergências de estado, em que o PMS mostra o quarto pronto e o housekeeping o mostra como sujo, são resolvidas através de uma rotina diária de reconciliação que compara ambas as listas de quartos e sinaliza as diferenças em vez de as substituir silenciosamente. As falhas no envio de webhooks resolvem-se com novas tentativas automáticas (retries com backoff) juntamente com a mesma reconciliação como rede de segurança. As alterações nos campos por parte do fornecedor após uma atualização de API resolvem-se através do controlo de versões da sua tabela de mapeamento, permitindo ver o que mudou e reverter se necessário.

Mantenha um plano de escalamento documentado por escrito, incluindo os elementos que o fornecedor do seu PMS necessita para investigar: carimbo temporal (timestamp), endpoint, identificador do pedido e o quarto afetado.

Quando 30 dias não é o plano adequado

Este plano pressupõe condições que nem todos os hotéis reúnem, e é preferível saber isso na semana zero.

• PMS local (on-premise) sem API ou com acesso pago à interface. A integração pode continuar a valer a pena, mas o calendário será determinado pelo processo comercial do seu fornecedor, e não por este plano. Obtenha o orçamento da interface antes de planear qualquer outra coisa.

• Várias instâncias de PMS num mesmo grupo. Comece por concluir um hotel de ponta a ponta. Gerir quatro hotéis em três versões distintas de PMS em paralelo transforma um plano de 30 dias num projeto de seis meses.

• Hotéis de dimensão muito reduzida. Abaixo de aproximadamente 25 quartos com apenas uma pessoa na limpeza, uma lista partilhada de tarefas trará a maioria dos benefícios e um projeto formal de integração constitui uma complexidade desnecessária.

• Casos em que a Sweeply não é a solução. A Sweeply é uma camada operacional sobreposta ao PMS, e não um PMS, uma plataforma de integração ou uma licença de middleware. Se o que procura é um pipeline de dados de âmbito geral entre finanças, POS e sistemas de BI, trata-se de outra ferramenta e de outro projeto.

Inicie a conversa sobre o mapeamento

Agende uma reunião com a nossa equipa comercial indicando o nome e a versão do seu PMS, o número de quartos e a data pretendida para entrada em funcionamento. Confirmaremos a compatibilidade da integração e indicaremos quais dos quatro objetos mencionados necessitam de trabalho de mapeamento no seu caso.