Barracudas: Custom Booking System API, Rebuilt Around Guest Checkout

Challenge

Parents could not see a price or check availability without creating an account first. For someone comparing providers on a phone, that is a wall in front of the only two questions they have.

Booking behaviour had changed too. Families now assemble the holidays week by week and decide late, which is difficult for an operator whose staffing is planned to expected numbers.

Underneath, the journey lived inside the portal as Razor pages. The website and the booking process were two experiences with a handover in the middle, and neither could change without the other.

Rebuilding the journey as an API

We pulled the booking journey out of the portal’s Razor pages and rebuilt it as a versioned HTTP API: around a dozen endpoint groups covering camps, children, dates and availability, clubs, courses, friend requests, merchandise, promotions and payments.

A separate front end, built by a third-party developer engaged by Barracudas, consumes it and is served from the main marketing site. Booking and website content now sit side by side, so the journey runs continuously instead of handing the parent over halfway.

Versioning means the front end can be redesigned, extended or replaced without putting the system that takes the money at risk. For a seasonal business, changing the shop window without touching the till is worth more than any single feature.

Booking without an account

A Barracudas booking is not one item in a basket. It is several children, each with their own weeks and days, clubs, courses, friend requests and merchandise, priced against availability that moves while you shop.

A visitor can now build all of that and reach a fully priced basket with places genuinely held, before an account exists. Registration happens at payment, and the anonymous basket merges into the new or existing account.

Holding real places for an anonymous visitor is what makes it work. A quote nobody can act on is just a price list. The same foundation made sharing possible: a parent can send a basket to a partner for approval before paying, and signed-in customers can save a draft and come back to it.

Special educational needs are captured progressively, opening only as far as each family needs. Where a child would need one-to-one support, the journey says so early and asks the parent to call, rather than letting them complete a booking that has to be unpicked later.

Designed before it was built

The journey was wireframed and signed off with the Barracudas team before the system was written, across several rounds of review. The people who answer the phones changed the design.

• Friend requests moved to after date selection, because the office administers them per week
• Sold-out days gained a waiting list state, turning a dead end into captured demand
• The number of children selector came off the camp page, removing a decision nobody needed to make yet

Those wireframes became the specification. What attaches to a child, the order the questions are asked in, and which rules the engine enforces were all settled in design. The API took its shape from the journey rather than the journey being fitted around the API.

Keeping the detail without the overwhelm

The hard part was not removing information. It was keeping it.

Parents need to know what each day costs, what is nearly full, what flexible cover does, how childcare vouchers work and how special educational needs are handled. Cut it, and they ring the office. Show it all at once, and a parent committing several hundred pounds on a phone gives up.

So we changed when each piece appears, not whether it appears. Eight steps, one kind of question each, price moving as they go.

• Day cells carry price, saving and availability state, so nothing needs a click to check
• Full week pricing sits beside daily pricing as a lower rate per day
• Flexible cover is offered where dates are chosen, with the explanation in place
• The basket updates live and becomes a pinned bar on a phone
• All five ways to pay appear together at the summary
• Vouchers and tax-free childcare get an explained page, not a field that fails silently

Inside the portal, an existing customer amending a booking sees everything on one page. Same decisions, different presentation, chosen for the person’s state of mind.

The portal

As part of building the custom booking system, the customer portal also needed to reflect the same design language, so booking and managing a booking feel like one product. Draft bookings gained a home with the option to finish or share them, and essential information forms now show as a status against each child rather than a warning at the point of purchase.

Two teams, one journey

Barracudas brought in a third-party developer to build the new website. We built the engine, the API, and the journey design behind it, and worked alongside them to integrate every endpoint.

Most bespoke systems reach this point eventually. The client changes developer or platform, and the question becomes whether the system can accommodate it. The API was the contract that made a split delivery work, and the journey launched at the start of the booking season without drama.

Results

From Barracuda’s own booking data, comparing the summer season before launch with the summer after:

• 5.4% more confirmed bookings, 1,260 additional bookings
• 5.5% increase in booking sales value
• 4% more bookings from new customers

Figures reviewed and approved for publication by Barracudas.

When a subscription platform does not fit

Off-the-shelf booking platforms work until your business stops looking like everyone else’s. Then you are paying every month, often a percentage of every booking, for features you will never use, and still cannot get the one thing you actually need.

Barracudas own their custom booking system. It fits how they operate: activity choice per session, flexible cover, skills courses, childcare vouchers, tax-free childcare, friend requests administered per week. No platform sells that combination, and none would build it.

This is the work we do when bookings are the business rather than a feature of it.

• A system you have outgrown, and a front end you want to change
• A signup wall you suspect costs more than it protects
• A complex purchase people start and abandon
• A platform taking a cut of revenue for something that half fits

Use the form or click the button to talk to us about what you want from your ideal booking system.