One purchase, two bookings: designing ticket packages

A package on TicketingHub used to be one ticket with vouchers attached. The customer booked a date for the first product and got a voucher for everything else, to be redeemed later.

In October 2025 a new client asked for something the platform could not do: a combo ticket for two attractions, where the customer picks the ticket quantities once and then a date and time for each attraction. The two visits could be days apart, and the second had to start well after the first.

The engineers could not estimate it. Bartosz Blimke wrote in the ticket that the flow had to be designed first, "to avoid surprises", and the planning ticket listed most of the backend work as blocked until the UX flow was defined. I designed that flow, the basket, and the supplier's side in the dashboard. Bartosz built the widget and the rules behind it, Pawel Krysiak built the dashboard flow, Attila Csizmadia ran the project and Carl Pihl made the product calls. The client's version was finished on 23 December 2025, and packages were switched on for every supplier on 27 January 2026.

One flow for every kind of package

The requests did not agree with each other. Some clients expected both visits on the same day, and the new one wanted them days apart. A zoo sells an entrance that is valid all day together with an experience at a fixed time. Carl described a bundle of six events spread across a week and wanted one booking flow for all of them.

The existing layout put both products on one screen. The notes from the planning meeting say this "could become very long and confusing" and suggest going step by step. I sent a first flow as a recording on 22 October. In that flow the dates came before the tickets. Two days later I wrote in the ticket that packages should always start with tickets. That is how it shipped: the customer picks quantities once, and both calendars then check availability for exactly those tickets.

After the tickets, the customer schedules one activity at a time. Each activity is a row that opens, and a bar above the rows counts how many are scheduled. The date opens in a drawer over the widget, so the list of activities stays where it was. A product sold as a voucher appears as a grey card with nothing to schedule.

The package step lives in the booking widget, which I also designed, and it reuses the widget's calendar and time buttons.

The supplier sets two rules

What the customer can pick depends on what the supplier allows. The supplier creates a package in a modal with three steps: the two products, the scheduling rules, and then how each product is issued and who can buy it.

A few details from the shipped modal:

• The first step moves on by itself once both products are chosen.
• Each step says in one line what the next step will ask.
• A product that can only be sold as a voucher has its Ticket option disabled, with a link to the setting that controls it.
• The line under the products always reads as a sentence: "Customers will receive a ticket for Old Town Food Tour and a voucher for Sunset Kayak Tour."
• Only customer types that both products sell are offered as tiers.

The buffer decision

My first design of the rules was a choice between two tabs. Same Day had an optional buffer between the activities. Flexible Window had a number of days and no buffer.

Bartosz replied the next morning that the two rules are not exclusive. His example was a spa package that needs two hours between a massage and a mud bath, with both inside seven days. He proposed a maximum span and a minimum gap that work independently.

The discussion ended on 13 January with the buffer kept under both tabs. In the code they are two separate rules. A time is greyed out when it overlaps the other activity plus the gap on either side, and a day is struck through when it falls outside the span.

One item in the basket

The ticket for the basket asked whether a package should show its own tiers or the bookings inside it. I designed it to show both. The package is one item with a badge, a name and one price. Opening it lists each booking with its date, time and tickets. The Order Summary on the payment screen repeats the same item.

My design also struck through the original price next to the package price, for the package and for each ticket inside it. That part has not shipped. The basket shows the package price only, and showing the discount is a separate ticket in the backlog.

Polish after the build

When Bartosz finished the flow I went through it and wrote that it needed only minor CSS tweaks, which I would do myself. That became a small pull request: the package badge styled the same in the step header, the basket and the summary, a date button as tall as the other inputs, a blue border on the open activity, and a smooth open and close.

In February I designed the same purchase for the point of sale. A package sits in the product list next to single products, and the step where each product gets its own date works a little differently there.

What is not done

The rules offer Same Day, but the widget does not have a same-day flow yet. The work before Christmas went into the multi-day flow the first client needed, and the same-day version was deferred. Today a customer with a same-day package still picks a date for each activity. The follow-up ticket describes what is missing: pick the date once, go straight to the second time, and say on screen that both activities happen that day.

Extras are open too. I designed how a package handles them, and the build is still in the backlog.

Outcome

Packages with two tickets are live for every supplier, in the widget, the dashboard and the point of sale. Since the launch the team has added descriptions, cover images, questions and mapping between ticket types.

For the customer it is one purchase. They choose tickets once, schedule two activities under rules they never have to read, and pay for one item. The same idea of selling two products together, without a package, is in the quiet upsell.

Working together

I designed this one: the customer's flow in the widget, the basket, and the supplier's setup in the dashboard. Bartosz Blimke and Pawel Krysiak built it, and I did the CSS polish at the end.

If you are planning something similar, I am taking on new work. Write to hello@edigil.com or use the contact page.