TI para hoteis e restaurantes: PDV, wifi de hospede e continuidade no atendimento

Por que TI em hotelaria e food service é diferente de escritório

Em um escritório comum, uma indisponibilidade de rede por vinte minutos gera irritação e algum retrabalho. Em um restaurante às 20h de sexta-feira, a mesma indisponibilidade significa fila na porta, comanda perdida, cozinha sem pedido e cliente indo embora. Em um hotel no check-in de um grupo de trinta hóspedes, significa recepção travada, chave não emitida e reclamação em plataforma de avaliação no mesmo dia. A diferença central não é a complexidade técnica do ambiente — muitas vezes ela é até menor que a de uma indústria — e sim a janela de tolerância: o negócio opera em picos concentrados e não tem como "resolver depois".

Essa característica muda a ordem das prioridades de infraestrutura. Em TI corporativa tradicional, a discussão costuma começar por produtividade, colaboração e gestão de documentos. Em hotelaria e food service, ela começa por continuidade do ponto de venda, estabilidade de rede em horário crítico e isolamento entre o que é operação e o que é conveniência do cliente. Ferramentas de escritório continuam existindo, mas são camada secundária: se o PDV cai, nada mais importa naquele momento.

Há ainda um fator de ambiente físico que raramente aparece em projetos genéricos. Cozinha tem calor, gordura e vapor. Área de piscina e varanda têm umidade e obstáculos de propagação. Salão tem densidade de pessoas variando de vazio a lotado em uma hora, e corpo humano absorve sinal de 5 GHz. Um projeto de rede desenhado na planta baixa, sem considerar ocupação real e materiais de parede, entrega cobertura no papel e reclamação no salão.

PDV: o sistema que não pode parar

O ponto de venda é o coração transacional do negócio. Qualquer arquitetura de TI para hotelaria e restaurante deve ser desenhada de trás para frente a partir dele: o que precisa acontecer para que a venda seja registrada e o pagamento seja capturado mesmo em cenário degradado? Responder isso com honestidade normalmente revela dependências invisíveis — link único de internet, servidor local sem redundância, aplicação que exige nuvem para abrir comanda, impressora fiscal ligada a uma única estação.

Três decisões concentram a maior parte do ganho de disponibilidade:

• Modo offline real e testado. Muitos PDVs anunciam operação offline, mas travam em alguma etapa específica — consulta de estoque, validação de fidelidade, autorização de desconto. Testar significa desconectar o link em ambiente controlado, rodar um ciclo completo de venda e verificar a sincronização posterior sem duplicidade.
• Redundância de link com failover automático. Dois provedores distintos, preferencialmente com meios físicos diferentes (fibra e link móvel), em roteador que faz a troca sem intervenção humana. Failover manual em pico de movimento é failover que não existe.
• Energia protegida por nobreak dimensionado. Não apenas o servidor: switch, roteador, access point da área de caixa e as próprias estações. Nobreak que mantém o servidor de pé enquanto o switch morre não sustenta a operação.

Vale também separar o PDV do resto do tráfego em VLAN própria, com regras de firewall restritivas. Isso reduz superfície de ataque, evita que um download pesado no administrativo degrade a rede do caixa e simplifica a investigação quando algo dá errado. Monitoramento contínuo de disponibilidade das estações e impressoras fecha o ciclo: a equipe de TI deve saber que uma impressora de cozinha caiu antes que o garçom descubra.

Wi-Fi de hóspede: conveniência sem abrir a operação

Wi-Fi é hoje um dos itens mais avaliados por hóspedes e frequentadores, e também um dos vetores de risco mais subestimados. O erro clássico é usar uma única rede — ou duas redes com SSIDs diferentes que terminam no mesmo segmento lógico. Nesse cenário, o notebook de um visitante desconhecido enxerga o servidor de PDV, o NAS de câmeras e as impressoras administrativas. Basta um dispositivo infectado para transformar cortesia em incidente.

A segmentação correta separa, no mínimo, quatro domínios de rede:

1. Operação/PDV — caixas, servidor de retaguarda, impressoras de pedido e balanças.
2. Administrativo — computadores de gerência, financeiro, RH e arquivos internos.
3. Hóspede/cliente — acesso à internet com isolamento entre clientes (client isolation) e sem rota para as demais VLANs.
4. IoT e dispositivos prediais — câmeras, controladores de acesso, automação de ar-condicionado, TVs e mídia indoor.

Na rede de hóspede, alguns controles são baratos e resolvem quase todo o problema operacional: limite de banda por dispositivo para que um usuário não consuma o link inteiro, priorização de tráfego para que o PDV nunca dispute com streaming, filtro de conteúdo para bloqueio de categorias ilícitas e portal de captura com aceite de termos de uso. O portal também tem valor comercial legítimo — pode coletar contato com consentimento explícito, alimentando ações de relacionamento dentro das regras da LGPD.

Regra prática: se um dispositivo de hóspede consegue enviar um pacote para o servidor de PDV, o projeto de rede está errado, independentemente de qual firewall está instalado.

Dados de cartão, PCI DSS e responsabilidade sobre o pagamento

Todo estabelecimento que aceita cartão está sujeito ao PCI DSS, o padrão de segurança da indústria de meios de pagamento. Na prática, o nível de exigência varia conforme o volume de transações e, principalmente, conforme a arquitetura adotada. A boa notícia é que a maioria dos pequenos e médios negócios pode reduzir drasticamente o escopo de conformidade tomando uma decisão simples: nunca deixar dados de cartão trafegarem ou serem armazenados no ambiente próprio.

Isso significa priorizar terminais com criptografia ponto a ponto (P2PE) ou soluções em que a captura acontece no equipamento da adquirente, e o PDV recebe apenas um token e uma confirmação. Quando o número do cartão não entra na rede da empresa, a rede da empresa deixa de ser um alvo relevante e o esforço de auditoria cai proporcionalmente. É o oposto do que ainda se vê em algumas operações de hotelaria, onde números de cartão de garantia de reserva ficam anotados em planilha compartilhada ou em campo livre do sistema de reservas — prática que cria responsabilidade jurídica desnecessária e é vedada pelo padrão.

Controles complementares que sustentam a conformidade sem burocracia excessiva:

• Senhas individuais por operador, sem contas compartilhadas de caixa, com rastreabilidade de quem fez cada cancelamento ou desconto.
• Atualização regular de sistema operacional e aplicação do PDV, com janela de manutenção fora do horário de pico.
• Antivírus/EDR nas estações de caixa e retaguarda, com alerta centralizado.
• Inventário atualizado de dispositivos conectados — não se protege o que não se conhece.
• Retenção de logs de firewall e acesso, úteis tanto para auditoria quanto para investigação de fraude interna.

Vale lembrar que a LGPD convive com o PCI DSS e amplia o escopo: dados de hóspedes, documentos de check-in, imagens de câmeras e listas de contato coletadas no portal de Wi-Fi são dados pessoais e exigem base legal, prazo de retenção definido e controle de acesso.

Continuidade em horário de pico: processo, não só equipamento

Redundância técnica resolve metade do problema. A outra metade é operacional: o que a equipe faz nos primeiros cinco minutos de uma falha. Em negócios com alta rotatividade de pessoal, como food service, o conhecimento não pode depender de uma pessoa específica. Ele precisa estar em procedimento curto, impresso, afixado próximo ao caixa e treinado no onboarding.

Um plano de contingência útil cabe em uma página e responde a poucas perguntas: como registrar venda se o sistema não abrir; como cobrar se a maquininha integrada falhar (terminal avulso de backup, com bateria carregada e chip ativo); a quem ligar, em que ordem, com qual número; e como lançar no sistema o que foi feito manualmente, depois que tudo voltar. A ausência dessa última etapa é o motivo mais comum de divergência de fechamento de caixa após incidentes.

Do lado da TI, três práticas reduzem incidentes em pico de forma consistente:

• Congelamento de mudanças em janelas críticas. Nada de atualizar servidor, trocar switch ou aplicar patch na sexta à tarde ou na véspera de feriado prolongado.
• Backup com teste de restauração. Backup que nunca foi restaurado é hipótese, não garantia. A validação deve ser periódica e documentada, com cópia fora do local (nuvem ou site secundário) para proteger contra ransomware e sinistro físico.
• Monitoramento proativo com alerta antes do usuário. Temperatura de rack, espaço em disco, saúde de link, disponibilidade de impressoras e APs. Falha silenciosa vira crise no pior horário possível.

Também é sensato revisar o SLA do fornecedor de TI à luz do horário real do negócio. Suporte "em horário comercial" é incompatível com restaurante que fatura à noite e hotel que faz check-in no domingo. Cobertura estendida e atendimento remoto imediato costumam custar menos do que uma única noite parada.

Como a Duk estrutura esse ambiente

A Duk Informática & Cloud atende mais de 550 empresas e acumula mais de 18 anos de experiência em infraestrutura, redes e segurança, incluindo operações com horário crítico como hotelaria, food service e varejo. A abordagem parte de um diagnóstico do ambiente físico e da rotina de pico — não de um catálogo de produtos — para então desenhar segmentação de rede, redundância de link, proteção de energia e política de backup compatíveis com o risco real da operação.

Como Microsoft Gold Partner, a Duk integra a camada administrativa em Microsoft 365 com controle de identidade, MFA e políticas de acesso, mantendo essa camada isolada do segmento de PDV e da rede de hóspedes. O data center próprio em Alphaville sustenta backup fora do local, réplicas e serviços em nuvem privada, com monitoramento contínuo e suporte 24/7 sob SLA — cobertura pensada justamente para negócios que faturam fora do horário comercial.

Na prática, o resultado esperado de um projeto bem executado é discreto: o caixa abre, o pedido chega à cozinha, o hóspede conecta sem pedir ajuda na recepção e ninguém precisa falar sobre TI durante o serviço. Se você opera um hotel, restaurante ou rede de food service e reconhece algum dos sintomas descritos aqui — rede única para tudo, link sem redundância, backup nunca testado ou plano de contingência que existe só na cabeça do gerente — vale uma avaliação estruturada antes do próximo pico de movimento.