What ROLLER gives a website
ROLLER is venue management software for attractions, and from a website's point of view two parts of it touch your pages.
Online checkout. A hosted booking flow on ROLLER's domain, with an embeddable checkout you can place on your own page and links you can point at from anywhere on the site. The parent picks a party package, a date and a slot, adds guests and add-ons, pays a deposit and lands in your calendar.
Waivers and forms. The digital waiver or party form parents complete before arrival, attached to the booking rather than sitting on a clipboard by the door.
Everything else ROLLER does, the point of sale, the memberships, the capacity management, happens after the booking and does not affect your pages. Feature detail changes release to release, so confirm the specifics of any embed or link option with ROLLER before you build a page around it.
The rule: nothing loads until the parent taps Book
The common mistake is dropping the checkout script into the footer of every page. A party venue site is mostly read rather than booked: the packages, the room photographs, the FAQ, the reviews. Loading a third party booking bundle on all of them slows the pages doing the persuading, for the benefit of the one page doing the booking.
So: one booking page carries the embed. Every other page links to it.
The booking page
Give it a clean address such as /book-a-party, with nothing on it but the checkout, one reassuring line, the phone number and your opening hours. Reserve the height before the widget arrives so the page does not jump as it loads, and preconnect to the booking domain in the head:
<link rel="preconnect" href="https://ROLLER-checkout-domain.example">
<div class="booking-embed" style="min-height: 820px"><!-- ROLLER checkout embed --></div>Above the embed, three lines that stop the calls you get most: what the parent will be asked for (date, slot, package, estimated number of children), what the deposit is, and when final numbers and dietary needs are due. Below it, the rescheduling and cancellation window. Do not repeat the package table here; link back to it.
Deep links from the package pages
Each package gets its own Book button, pointed at the checkout with that package already selected where ROLLER's links allow it. The toddler package opens the toddler party, not the two hour package for eight year olds.
If a package cannot be deep linked, the button still goes to the booking page and the line above the widget names the package so the parent knows what to choose.
Configure ROLLER before the site points at it
- Party rooms as separate resources, each with its own capacity, so no room is sold twice and no thirty child party lands in a room that holds eighteen.
- Session times and turnaround, so the changeover for clearing and resetting is protected between parties.
- Packages priced per child with a minimum, matching the package table on the site exactly, with extra children charged per head.
- Food options as structured choices rather than a free text note, with the allergens page linked from the flow.
- Add-ons priced individually: party bags, adult catering, cake, decorations, character visits, extra play time, each with its own lead time where it needs one.
- Deposit and balance schedule, with the terms in the same words the parent agrees to.
- Waivers and party forms sent with the confirmation rather than handed out at the door.
- Automatic requests for final numbers, food choices and allergies before your deadline.
- Confirmation and reminder templates carrying arrival time, parking, what to bring and the balance date.
Then book a test party from your own phone, end to end, and cancel it.
The header does not change
ROLLER does not reorganise the site. The header on every page still carries the phone number, Book a party and Packages. On phones, a slim bar fixed to the bottom with Call and Book. A parent who is worried about her son's dairy allergy wants the FAQ, then the button, in that order.
Testing, especially in-app browsers
A large share of party traffic arrives from a link in an Instagram bio, and Instagram's in-app browser is not Safari. Test the whole route there and in Facebook's, plus Safari and Chrome on iOS and Android: pick the package, choose a slot, add guests and add-ons, pay the deposit, receive the confirmation.
If the embed misbehaves in an in-app browser, send those entry points to ROLLER's hosted checkout instead. Repeat the test monthly.
Tracking
Add a booking_click event on every Book tap with the page and package as parameters, and a call_click on every tap to call. Once a month, compare taps by page against completed bookings in ROLLER. That tells you which package page fills the rooms and which is read and abandoned, usually the one whose price or minimum is vaguest.
Common mistakes
- The checkout script on every page, slowing the photo gallery for everyone who is only looking.
- Prices in ROLLER drifting away from the package table after a rate rise.
- One generic party slot instead of rooms as resources, so double bookings become your problem to spot.
- Allergies and final numbers chased by hand on a Thursday evening.
Where this sits
ROLLER is the platform we wire in most often on a children's party venue website, and the pattern is the same one we use across childcare and family websites: one booking page, deep links from the package pages, the phone and the FAQ ahead of both, tracking on everything. ROLLER holds the rooms. The site's job is to answer the price question and open the checkout in one tap.