Delivery deep dive
Four days to a deposit
I led the final push to launch booking deposits before a major ferry operator released its next season of sailings. The biggest decision was what could wait.
The deadline
Ready before the timetable dropped
A timetable release opens next season's sailings for booking. For this operator, it brought roughly three times as many customers into the cart on release day. For sailings more than two months away, it was about five times as many. People were ready to book next summer's crossing as soon as it went on sale.
That usually meant paying the full fare months before travelling. Deposits would let customers pay part now and the balance, the rest of the fare, closer to departure.
Discovery and some of the build were already done when I became project lead on Monday morning. The timetable release was the following Monday. I rewrote the scope around that date, split it into day-sized tasks and led the team through the remaining build. By Thursday it was complete. On Friday it was available to every customer on eligible sailings.
My part: project lead, scope and task breakdown, daily risk check-ins, stakeholder updates, and hands-on work mainly in search results and the cart. Colleagues built the operator booking path, confirmation emails, terms and launch switch.
Scope
Ship the deposit. Build the balance next.
A customer needed to see the deposit option, understand the terms, pay the deposit and leave with a real booking. Everything else had to earn its place in the first release.
The cut that changed the plan
The first balance wasn't due until about three weeks after the first deposit. We had four days to ship deposits, but weeks to finish balance payments. I moved that work out of the launch and into the work immediately after it. It shipped in time.
What stayed in
- Deposit availability on search results.
- The normal cart journey, charging only the deposit.
- A deposit booking placed with the operator straight away.
- Terms before payment and an email stating what was paid, what remained and when it was due.
The other scope decisions
- Changes and cancellations
- Disabled for deposit bookings until the balance was paid, rather than building every combination for launch.
- Return journeys
- One-way journeys at launch because the operator's system broke on deposit returns. I built the two-one-way booking approach afterwards.
- Deposit options
- One option rather than a choice of several.
- Route restrictions
- Offered deposits wherever the operator supported them, instead of maintaining a separate route list.
- Rollout
- Available to all eligible customers. A 50/50 experiment would have withheld deposits from half of the release-day demand.
Delivery
From scope reset to first payment
- Monday
Rewrite the scope
Split the work into a dozen day-sized tasks. First changes merged.
- Tuesday
Search results ready
Customers can see which sailings offer a deposit.
- Wednesday
Payment and booking
Cart steps, the deposit-only charge, operator booking path and terms merged.
- Thursday
Build complete
Deposit prices, booking details, quote caching and blocked changes in place. Live behind a switch.
- Friday
Open to every customer
The switch came off. The first deposit was taken that afternoon.
- Next Monday
Timetable release
Deposits available before the surge in next-season bookings.
Leading the work
End each day on the biggest risk
Alongside the morning standup, I ran an end-of-day sync with the people building the feature. The question was specific: what is the biggest risk to Thursday, and what do we do about it?
That conversation drove the balance-payment cut. Checking its real due date turned a four-day problem into work we could finish after launch.
It also put customer communication on the critical path. While balance payments and booking changes were still to come, the emails needed to explain the payment split, due date and terms clearly.
I kept stakeholders up to date on what was finished, what we'd moved and why. The scope stayed visible, decisions were made quickly and the team could keep building.
Follow-up
One return journey. Two operator bookings.
At launch, deposits only worked for one-way journeys. The operator couldn't handle a return journey as a deposit booking, so I built the follow-up around what it could handle: two one-way bookings.
The customer still sees one booking and pays one deposit. The split happens behind that experience.
The customer chooses a return journey and pays one deposit. We keep one customer-facing booking.
Read the full sequence
- One customer booking. The customer chooses a return journey and pays one deposit. We keep one customer-facing booking.
- Both legs in parallel. We book the outbound and return legs with the operator at the same time, as two one-way deposit bookings.
- One experience, two bookings. The operator has two one-way deposit bookings. The customer still sees one return booking and has paid one deposit. This follow-up shipped after the initial one-way-only launch.
Impact
A payment option customers chose
Full payment remained available alongside it. Customers were choosing to spread the cost, and we had the option ready before the timetable opened.
Operator orders per day were broadly unchanged in the two weeks before and after release, matching the pattern from the previous year. These results show adoption of deposits, rather than a measured increase in total orders. The release went to everyone, so there was no control group to isolate the effect on bookings.
That gave us a clear basis for expanding the feature: customers were using it, and the balance-payment and return-journey work shipped soon after. The next measure is how many deposit customers complete the balance payment.
The result
The deadline shaped the release
I took a partly built feature, turned it into a four-day delivery plan and kept the team's attention on the decisions that could change the outcome. We launched to every eligible customer before the operator's timetable release, then shipped the balance payments and return journeys afterwards.
The speed came from separating what customers needed on release day from what they needed later.
Words used on this page
- Balance
- The remaining fare, paid after the deposit and before travel.
- Control group
- Customers who don't receive a change, used to compare its effect.
- Ferry operator
- The company that runs the ferries and whose tickets we sell.
- Launch switch
- A setting that turns a finished feature on or off without another release.