What we are building
Party packages on a venue site are not a picture of a price list. They are a small set of records with fields, rendered as comparable cards on a phone and a table on a laptop, matched to the products set up in your booking platform, and editable by you in ten minutes when the price of party bags changes.
This is the build order we use. It takes an afternoon the first time.
1. Get the packages out of your head and into a grid
Before anyone touches a website, write the grid. Packages down the side, fields across the top. Age range, party duration, room time including setup and clearing, what is included, price per child, minimum number of children, price per extra child, and what is not included.
Fill every cell for every package. If two packages differ only in the food, that will be obvious in the grid, and it is usually a sign to merge them or to make the difference an add-on instead.
2. Write the inclusions as items, not sentences
This is the step that makes the packages comparable. Play time, party host, hot or cold food, drinks, ice cream, invitations, party bags, decorations, a gift for the birthday child. Each one an item that is either present or absent for each package.
Rendered as a list with the absent items visible rather than silently missing, a parent can see the difference between your bronze and silver in two seconds. That is the whole point of the exercise.
3. Set the packages up in the platform before the website
Configure the products in ROLLER, Bookeo, Xola or Party Center Software first: the party duration, the room turnaround, the per head pricing, the minimum, the deposit and the add-ons as that platform models them.
Then write the website's package pages from the platform. Doing it in that order means the price a parent reads on the site is the price the booking flow charges. Doing it the other way round guarantees the two drift apart within a season, and the drift is discovered by a parent at the desk.
4. Model it as records, not as a hard-coded page
In the CMS, a package is a record with fields: name, age range, duration, room time, inclusions, exclusions, price per child, minimum children, price per extra child, deposit, a short line on who it suits, a photo, and the deep link into the booking platform. An add-on is a separate record with name, price, price unit and a short description.
The page renders whatever records exist. Add a package and a card appears. Change price per child and every page that mentions it re renders. Nobody opens code, and nothing goes stale because a developer was busy in March.
5. Build the add-on list underneath
The package covers the standard party. Everything else is its own line with an honest price unit: party bags per child, an extra half hour on the room, a themed decoration set, a character or entertainer visit, extra adults for food, a cake if you supply one, exclusive hire.
Price units matter. Party bags, per child is defensible. Party bags, from is not.
6. Write the numbers rules in plain words
Under the packages, three or four sentences on the parts that cause trouble later. The minimum charge and that it applies whether or not the children attend. When final numbers are confirmed, usually a week before. Whether numbers can go up on the day and how far. What happens to the deposit if the party is cancelled or moved. This paragraph prevents almost every awkward conversation at the end of a party.
7. Add one honest line about who each package suits
A parent with a four year old and a parent with a nine year old are looking at the same page. One line per package saying who it is for, and who it is not, moves parents to the right package and stops the wrong booking before it happens.
8. Lay it out for a phone
Most party research happens on a phone. A four column comparison table does not fit one. Either let the table scroll horizontally inside its own container with the package names pinned, or stack it: one card per package with the inclusions listed inside. Test it on a real handset, not a narrowed browser window.
Keep the price per child large enough to read one handed, and never put prices inside an image, which search engines cannot read and screen readers cannot speak.
9. Put booking next to the price
On every package card, a Book button deep linked into the platform with that package already selected, and the date picker as the first thing the parent sees. They have just decided what the party costs, which is the exact moment they are willing to act. Sending them to a general contact page loses a share of them.
10. Test, then set a review date
Book a test party at each package on a phone and check that the site price, the platform price and the deposit all agree. Run the same test inside the Facebook and Instagram in-app browsers. Then put a reminder in the calendar twice a year, and edit the records the day you change what you charge rather than the week after.
Where this sits
Packages as editable records with inclusions, price per child and minimums, add-ons priced honestly, and a Book button next to every number are part of every children's party venue website we build, and the same records pattern runs across our childcare and family websites. The packages that include it are on pricing. Build it once as records and it stays true for years.