Prom Module

Keeps the promise that no two girls from the same school leave your boutique in the same dress.

The Prom module tracks which gown is spoken for at which school, warns your team before a clash is sold, and gives girls a page where they can check a dress for themselves. It is switched off by default — turn it on under Settings → Modules.

Bridal-only boutiques

Leave it off. Nothing appears anywhere in BridalOp until you switch it on.

How it works

Every prom dress that sells to a girl with a school on her record is written into the Prom Registry against that school. From then on, anyone at the till or on the shop floor can see that it's taken — and if someone tries to sell it to another girl from the same school, BridalOp says so.

Matching is on style and colour, never size. Two girls of different sizes wanting the same gown is the ordinary case, not a clash. The same gown in navy and blush counts as two different dresses unless you tighten it.

Exclusivity belongs to the school, not the branch. A dress sold at your downtown store blocks it uptown, because the girls go to the same prom.

Setting it up

Three things, in this order. If you'd rather follow it end to end, including catching up on a season already in progress, see Setting Up the Prom Module.

1. Tell BridalOp which dresses this applies to

Settings → Prom → Which dresses this applies to.

This is keyed to the product type on each product — the field on the product page that says Gown, Bridesmaid, Prom, and so on. Tick the kinds that are prom stock.

The counter beside each kind tells you how many products you have of it, and the page will warn you plainly if your selection covers nothing at all:

Nothing is being tracked yet — No products in your catalogue match the kinds selected below.

That state is worth taking seriously. Switched on but matching nothing means no dress is ever registered and no clash is ever caught, while every screen looks like it's working.

Product type is not the same as category

A category named "Prom" that you created yourself is a different thing from the type Prom. The module reads the type. If your prom gowns are set to type Gown, either change them or tick Gown here.

2. Add your schools

Schools in the main menu, under Operations.

Add one with its name and, optionally, district, city and state. The extra fields are only there to tell two schools with the same name apart — plenty of counties have more than one Central High.

Each school only needs entering once. Entering it twice splits its own exclusivity, so the same dress could be sold to two girls who go to the same place without anything warning you.

Action	What happens
Search	Filters the list as you type.
Show inactive	Appears once you have any. Inactive schools are hidden by default.
Mark inactive	Stops the school being offered on forms and the public checker. Everything registered against it stays exactly as it was.
Delete	Only possible when no customer is assigned to it. Otherwise you're told how many are attached and asked to mark it inactive instead.

Marking inactive is almost always what you want. Deleting a school you have history with would take that history with it.

3. Put a school on your customers

New Customer and Edit Customer, where you'll find School, Year (Freshman through Senior) and Prom date. All three are optional; only the school affects exclusivity.

These fields only appear when the module is on, so bridal-only boutiques never see them.

Without a school on her record, nothing is registered when she buys and the promise silently does not cover that sale. That's the failure nobody notices until two girls arrive in the same dress, so it's worth being strict about.

You can have BridalOp insist on it — see Prom Settings.

Where it shows up

On the product page

Any prom dress shows how many schools it's spoken for at this season, expanding to the list with the colour and the date. A consultant pulling dresses for a Springfield girl can see at a glance whether it's worth taking off the rail.

In the POS

With a customer attached who has a school on her record, dresses she cannot have are badged in the product grid. No clicking through to find out.

On the appointment

A prom appointment carries her school and a count of how many dresses are unavailable to her, so the rail can be pulled before she walks in. This is the difference between the module being useful and being paperwork.

At the till

The last line of defence. If the earlier surfaces did their job this should almost never fire — but when it does, it behaves according to your enforcement setting and records every override.

The Prom Registry

Prom Registry in the main menu, under Operations.

Every dress spoken for this season, filterable by school and status, searchable by dress, style number or customer. A season selector switches between years, so last year's book stays browsable.

Status	Meaning
Registered	Sold. The dress is taken at that school.
On hold	Held for a girl who hasn't paid yet. Expires on its own.
Hold lapsed	A hold that ran out. No longer blocking anything — but she may be worth a phone call.
Released	Given back. The dress can be sold at that school again.

Adding a record by hand

For a dress sold before you switched the module on, a special order not yet placed, or a girl who has decided but hasn't paid.

Releasing a dress

A return, a cancellation, or staff correcting a mistake. You're asked for a reason, and the record is kept rather than deleted — who had it and why it went back is the part you need six months later, when two people remember it differently.

Overrides

When a dress is sold over the top of an existing registration, the registry says so and shows the reason given. If the promise is being broken, this is where it shows. Most overrides will be perfectly good — a different school's prom, two sisters — but a run of thin reasons is worth noticing.

Holds

Off by default. A hold takes a dress off the table at a school before it's bought.

Every hold gets an end date, because one without would block a dress for a whole season simply because somebody forgot. When it lapses it stops blocking automatically and shows in the registry as Hold lapsed — the dress is free again, and nobody had to remember to clear it.

Extend gives a girl longer. It counts from today, so extending a lapsed hold gives her the full run rather than putting it straight back into the past.

When a girl buys the dress she was holding, her own hold retires itself. A hold somebody else was sitting on stays exactly where it is — it's the record of the clash.

The public checker

/{your-booking-link}/prom/check

A page girls can use themselves: choose a school, search for a dress, get an answer. Your link is on the Prom Settings page, ready to copy onto your own website.

It never says who has a dress. Only whether it's free at that school. Your staff see a first name and last initial in the registry so they can have the conversation; the public page shows nothing of the kind.

When a dress is taken it can suggest what is still free at her school, which turns a disappointment into a second appointment.

The page stays hidden until the module is on, the checker is enabled, and something in your catalogue is actually covered — a checker that answers "free!" about stock it doesn't cover would be worse than not being there.

Prom appointments

Tick Prom appointment on an appointment type (Settings → Booking) and your public booking form asks for the girl's school, her year, and her prom date.

That's the cheapest place to get her school and the only one that happens before she's standing in your shop. It's optional even then — a girl who doesn't know it off the top of her head can still book, and your team can fill it in when she arrives.

Rebooking never changes a school already on file. A public form must not be able to move a girl to another school, which would silently free every dress registered against her old one.

Reports

Reports → Prom Season. Sales by school, most spoken-for styles, prom revenue, and every override with its reason.

Scoped to the season, not the date range at the top of the page — a dress registered in November belongs to the spring it was bought for. It isn't split by location either, for the same reason exclusivity isn't.

Like every other report it exports to CSV and PDF from the corner buttons; the CSV gives you the by-school breakdown, which is the one worth taking into a conversation about next season's marketing.

A dashboard card shows the season at a glance and, more usefully, holds running out this week — a hold that lapses quietly is a girl who was ready to buy and heard nothing back.

Seasons

Everything is scoped to a season, so last year's registrations stop blocking this year's sales without anyone clearing anything out. Roll the season over in Settings → Prom when you start selling for the next prom.

Who can see what

Screen	Needs
Schools, Prom Registry	The Customers permission — a school is how a prom customer is grouped, so anyone who can see customers can see these.
Prom Settings	The General settings permission. Enforcement decides whether the promise is kept, so it isn't left to whoever finds a clash inconvenient.
The public checker	Nobody signs in. It never returns a customer's name.

Names in the registry are shown to signed-in staff as a first name and last initial — enough to have the conversation, never enough to hand out who someone is.

See also

• Setting Up the Prom Module — a start-to-finish walkthrough
• Prom Settings — enforcement, holds, seasons, the checker
• Modules — switching the module on