Vouchers Digitais para um Grupo Hoteleiro

O que foi feito

Um grupo hoteleiro português quis substituir a venda manual de vouchers de oferta — spa, jantares, estadias — por um sistema próprio. Em vez de começar por escolher plataforma, construímos uma prova de conceito completa e funcional: microsite de compra, backoffice de gestão, API e ciclo de vida do voucher.

O problema não era a ideia, era a gestão

Vouchers de oferta têm boa mecânica financeira para hotelaria: recebe-se o dinheiro antes de se entregar o serviço, e quem resgata é frequentemente um cliente novo, trazido por outro.

Mas gerir isto à mão não escala. Cada voucher passa a ser um email, uma linha numa folha de cálculo e um PDF feito à pressa — e ao fim de uma época ninguém sabe ao certo quantos estão por resgatar, nem quanto dinheiro isso representa em serviço ainda por prestar.

A dúvida do grupo não era se queria vender vouchers. Era como é que aquilo funcionaria na prática, antes de comprometer orçamento com uma plataforma comercial.

O que foi construído

Três peças: um microsite público onde o cliente escolhe, personaliza e compra; um backoffice onde a equipa gere catálogo, emissões e estados; e uma API que serve as duas, com separação entre o catálogo público e as operações de administração.

O comprador pode oferecer a outra pessoa: o sistema separa quem paga de quem recebe, com mensagem e ocasião associadas. Oferecer é o caso de uso real, não uma funcionalidade decorativa.

O comprador que não é uma pessoa: incentivos e MICE

Um voucher de oferta parece um produto de consumo — alguém oferece um jantar a alguém. Mas o I de MICE é incentives, e aí o comprador é outro: é a empresa que compra duzentas experiências para a equipa comercial, o programa de reconhecimento interno, o brinde de fim de ano a clientes.

É o mesmo produto com uma economia diferente. Um pedido corporativo vale por cem individuais, repete-se com calendário previsível, e o comprador precisa de coisas que o particular não precisa: fatura com NIF, emissão em lote, prazos de validade alinhados com o ano fiscal, e alguém a quem telefonar.

A prova de conceito não resolveu esse canal — resolveu a compra individual. Mas mostrou que a estrutura o suporta: o sistema já separa quem paga de quem recebe, já regista NIF, e já tem catálogo por categoria. Passar do particular ao corporativo é acrescentar emissão em lote e faturação, não recomeçar. É a ligação natural entre este caso e a captação de pedidos MICE, onde o mesmo grupo hoteleiro tem o outro lado do problema.

As decisões que interessam

A base de dados é um ficheiro de texto, e foi de propósito. Um JSON simples, sem servidor de base de dados. Montar infraestrutura é gastar dinheiro antes de saber se o produto interessa. A migração está identificada como passo seguinte, para quando houver volume que a justifique.

O pagamento é simulado. Integrar um prestador exige contrato, conta de comerciante e conciliação — e nada disso responde à pergunta que a prova tinha de responder: o percurso de compra faz sentido, o catálogo cobre a oferta, a equipa consegue gerir isto?

Mandarim no catálogo. Não é ornamento. É uma decisão sobre que mercados emissores o grupo quer servir, tomada no momento em que custa quase nada tomá-la — antes de o sistema existir.

O que a prova entregou

Não foram vendas — não havia pagamento real. Foi uma decisão informada: o grupo passou a ver o produto a funcionar, com o seu próprio catálogo e a sua própria oferta, antes de escolher entre construir, comprar ou desistir.

E ficou uma lista curta e concreta do que falta para produção: integrar o prestador de pagamentos, gerar o PDF do voucher, envio de email transacional, migrar para base de dados, autenticação a sério no backoffice, e limitação de pedidos na API.

A prova de conceito não é uma versão pequena do produto. É a resposta barata a uma pergunta cara.

É o mesmo princípio que aplicámos no configurador de eventos e na previsão de stocks na saúde: uma pergunta estreita, com critério de sucesso escrito antes de começar. Se não passar, ficou barato descobri-lo.