How does RingUps know when a bride's gown has to arrive?
The deadline engine computes a must-arrive-by date backward from the wedding date, leaving room for shipping and fittings.
Client relationships
A bride is not a customer. She is one transaction that stays open for a year.
RingUps holds a bride as one record that stays open for eight to fourteen months: her wedding date, her venue, the party shopping with her, the gown she chose, the deadlines that run backward from the date, her fittings and her balance. It is not a contact with a deal attached. It is the whole transaction, in one place, for as long as it runs.
A general CRM models a contact and an opportunity with a close date you are free to move. Nothing about a wedding works that way, and the gap is not a field you can add.
2,902
bride records migrated off Bridal Web Solutions, verified 2026-08-04
3,570
customers live at Cande Bridal Boutique today, after trading since
The shape of the problem
Why can a general CRM not be bent into the shape of a bride record?
Retail software assumes a customer walks in, pays, and leaves. Bridal does not. A bride books an appointment eight to fourteen months out, arrives with her mother and three bridesmaids, tries a dozen gowns, agrees a budget out loud that nobody writes down, pays a deposit on a gown that does not physically exist yet, waits four months for it to be cut, comes back three times to be fitted, and collects it on a date that cannot move by one day.
In a general CRM that is a contact with an opportunity attached. The opportunity has a close date, and the close date is a forecast. In bridal the date is a fact about somebody else's life, and every deadline in the transaction is derived from it: when the gown has to be ordered, when it has to arrive, when the first fitting has to happen, when the balance has to be settled.
You can add custom fields to a general CRM. You cannot add the second half of the transaction, which is the workroom, the purchase order to the designer, the deferred deposit and the pickup. That is why RingUps carries the bride record rather than syncing to one.
| General CRM | Bride record in RingUps |
|---|---|
| A contact | A bride, plus the mother, the maid of honour and the bridesmaids shopping alongside her |
| A close date you can push | A wedding date that cannot move, and a venue she is walking into |
| A pipeline stage | A gown on order from a designer, with a must-arrive-by date computed backward from the wedding |
| A notes field | Appointments, fittings, measurements, the gown she chose and the ones she rejected |
| One payment on close | A deposit taken months before the gown exists, held as deferred revenue and recognized at delivery |
| Closed won | A pickup, a settled balance, and a party of people who now know the store |
The record
What is actually on a bride record?
One screen, loaded in a single pass rather than seven clicks: the wedding, the venue, the party, the gown, the order and its deadlines, the fittings, and what she has paid against what she owes. Every consultant who serves her walks in knowing her story, whether or not they were the one who sold it.
A dated timeline anyone can add to, with the consultant’s name on every entry, plus automatic entries for bookings, orders, payments and status changes
Saved views on the client book, including a Today tab: everyone who registered, arrived or paid today, on your own calendar day
A wedding countdown, and a bride carrying purchase history that the database itself refuses to delete
First enquiry to pickup
What happens to a bride record over fourteen months?
Six moments. What the staff member does, and what RingUps does in response. Each step is the point where a different module picks the record up.
-
She enquires and books
She books herself in from the store’s public booking page, or a staff member takes the call and books her. Either way the bride record is created at that moment with her wedding date on it, and a confirmation email goes out. A real end-to-end self-service booking has run in production, from open slots to a confirmed row.
-
She comes in for the appointment
The consultant opens the record before the bride sits down: who is coming, what she said last time, what she is working with. Notes, the gowns tried and the gown she loved go on the timeline, dated, with the consultant’s name attached. The wedding countdown is on the record from this point onward.
-
She says yes
The order is written against her record, the contract is raised and the deposit is taken. The deposit does not count as revenue: it is held as deferred revenue in an append-only double-entry ledger and recognized when the gown is delivered, which is the only accounting treatment that survives a gown ordered in March and collected in October.
-
The gown is ordered from the designer
A purchase order is placed against her order. The must-arrive-by date is computed backward from the wedding date so there is room to ship and to fit. The dye-lot guard is enforced at the write path rather than as a warning on a screen: a mismatched lot blocks the placement, with an explicit override if the store decides to proceed anyway. The printable PO is the output. RingUps does not transmit it to the designer.
-
She comes back for fittings
The gown arrives, is checked in against her order, and the fittings are booked. The alterations workroom is one screen holding the queue, rather than the work being scattered across appointments, per-supplier charge records and four separate reports.
-
She collects the gown
The balance is settled at pickup and the record closes with the whole transaction on it: every appointment, every payment, every gown she tried, the party who came with her. Her purchase history is protected at the database level, so the record cannot be deleted out from under the accounts.
228 orders were skipped rather than fabricate a bride.
From the Cande Bridal Boutique migration. An order with no identifiable bride behind it was left out of the import rather than attached to a plausible one.
Proof
Twenty years of bride records moved in one weekend, and what we refused to move
Cande Bridal Boutique in Kelowna, British Columbia came off Bridal Web Solutions. These figures were verified against the production database on 2026-08-04. The store has traded since, so its live totals are higher, and a live total is never a migration figure.
Every imported row is idempotent on its source reference and reversible by batch id, so a migration that goes wrong is undone rather than argued about. The import was not pristine and we do not present it as such: 1,391 orders arrived carrying no tax at all and had it rebuilt, 36 exception invoices were corrected against Bridal Web’s own report, and every imported order landed with a picked-up status.
What it replaces
The four places a bride currently lives
The spreadsheet of wedding dates
Maintained by one person, current until the day she is away.
The whiteboard of gowns on order
Readable only in the back room, and only by whoever wrote it.
The paper file with the contract in it
Which is where the deposit amount is, when the bride phones about her balance.
The owner who keeps the rest in her head
The single most reliable system in most boutiques, and the one that cannot be hired for.
Where to go next
Appointments
Read this if you want to know how a bride gets onto the record in the first place, and what the booking policy fields do and do not enforce.
Special orders
Read this for the half of the transaction a CRM has no concept of: the purchase order, the must-arrive-by date and the dye-lot guard.
Client communications
Read this if you want to know exactly which emails a bride receives, which are off by default, and why a held message tells you the reason it was held.
Questions about the bride record
Bring last month’s brides to the demo
Fifteen minutes on your own data. We load your export, reconcile it against your own reports, and show you the records as RingUps would hold them.