Digital Gift Vouchers for a Hotel Group

What was built

A Portuguese hotel group wanted to replace the manual sale of gift vouchers — spa, dinners, stays — with a system of its own. Instead of starting by choosing a platform, we built a complete, working proof of concept: a purchase microsite, a management back office, an API and the voucher lifecycle.

The problem was not the idea, it was the administration

Gift vouchers have good financial mechanics for hospitality: you are paid before you deliver the service, and whoever redeems is often a new customer, brought in by someone else.

But running it by hand does not scale. Every voucher becomes an email, a row in a spreadsheet and a hurried PDF — and by the end of a season nobody knows exactly how many are outstanding, or how much service that represents as yet undelivered.

The group's question was not whether it wanted to sell vouchers. It was how it would work in practice, before committing budget to a commercial platform.

The three pieces

A public microsite where the customer chooses, personalises and buys; a back office where the team manages catalogue, issuances and states; and an API serving both, with the public catalogue separated from the administrative operations.

The buyer can give the voucher to someone else: the system separates who pays from who receives, with a message and an occasion attached. Gifting is the real use case, not a decorative feature.

The buyer who is not a person: incentives and MICE

A gift voucher looks like a consumer product — someone treats someone to a dinner. But the I in MICE is incentives, and there the buyer is different: the company buying two hundred experiences for its sales team, the internal recognition programme, the end-of-year gift to clients.

Same product, different economics. One corporate order is worth a hundred individual ones, it repeats on a predictable calendar, and the buyer needs things a private customer does not: an invoice with a tax number, batch issuance, validity aligned to the fiscal year, and someone to call.

The proof of concept did not solve that channel — it solved individual purchase. But it showed the structure supports it: the system already separates payer from recipient, already records a tax number, and already has a catalogue by category. Going from private to corporate is adding batch issuance and invoicing, not starting again. It is the natural link between this case and MICE lead generation, where the same kind of hotel group has the other half of the problem.

The decisions that matter

The database is a text file, and that was deliberate. A simple JSON file, no database server. Standing up infrastructure spends money before you know the product matters. Migration is identified as the next step, for when there is volume to justify it.

The payment is simulated. Integrating a provider requires a contract, a merchant account and reconciliation — and none of that answers the question the proof had to answer: does the purchase journey make sense, does the catalogue cover the offer, can the team run this?

Mandarin in the catalogue. Not ornament. It is a decision about which source markets the group wants to serve, taken at the moment it costs almost nothing to take — before the system exists.

What the proof delivered

Not sales — there was no real payment. An informed decision: the group could see the product working, with its own catalogue and its own offer, before choosing whether to build, buy or drop it.

And it left a short, concrete list of what production needs: integrate the payment provider, generate the voucher PDF, transactional email, migrate to a database, proper authentication on the back office, and rate limiting on the API.

A proof of concept is not a small version of the product. It is the cheap answer to an expensive question.

It is the same principle we applied in the event configurator and in stock forecasting in healthcare: one narrow question, with a success criterion written before starting. If it does not pass, it was cheap to find out.