RingUps puts the alterations workroom on a single screen: every gown in the room, the seamstress it is assigned to, the fitting date, the services pinned at that fitting and the price of each one. Bridal Web Solutions has no alterations workroom. The same work is spread across appointments, per-supplier charge records and four separate reports.
No boutique has run alterations through RingUps in production yet, so the screen below is the built module shown with sample data.
In four places, and none of them is the workroom. A fitting is an appointment. The money is a charge record filed under whoever did the sewing. What is actually happening in the room has to be reassembled from four separate reports, by the one person who already knows the answer. That person is usually the owner, and the reassembly happens on a Saturday.
Bridal Web Solutions is deep software dating to 2006, and this is not a shallow product. It simply never grew a workroom. There is no single screen to open on a Tuesday morning and see the room.
The difference is not a feature count. It is a difference in shape: work that was an inference drawn from four reports becomes a record you can open.
Intake, in progress, fitting booked, ready for pickup. Choose a stage to see what the screen holds at that point. Everything below is sample data in a built screen.
A job is opened against the bride's order the day the gown is received, so the bride, the gown and the wedding date come with it and nothing has to be retyped. The queue sorts by date. Nothing sits unassigned for a fortnight without being visible to whoever opens the screen.
A whole job goes to a seamstress by name, or a single line of it does, so a bustle and a hem on the same gown can sit with two different people. RingUps records no estimated hours and models no capacity, so there is no load bar and no percentage here. What you get is the list: who has what, and what is due when. That is deliberately less than a scheduling system claims and it is exactly what is in the product.
The fitting date lives on the job, which is where the person doing the sewing will look for it. It is a workroom record and not a calendar appointment: a fitting and an Alterations-department appointment are two records and they do not sync, so a fitting you also want on the shop calendar is booked twice. A booked fitting cannot be rescheduled or cancelled from the workroom.
Two numbers, and they are separate on purpose. The job total is the live sum of the service lines and it is recorded on the job. It is not added to the balance owing on her order: alterations charges are held outside the order total by design, so the payments ledger, the deposit ledger and the tax engine never see them. RingUps will tell you what the work was and what you charged. It will not collect for it.
Seven steps, written as the workflow the module was built for. Read it as the intended path rather than as a case study. Each step says what the staff member does and what RingUps does in response.
The gown arrives and a staff member opens an alterations job against the bride's order. RingUps carries the bride, the order and the wedding date onto the job, so the room inherits the same date the special-order deadline engine has been counting down to.
The staff member sets a fitting date on the job. RingUps stores it on the job and shows it on the workroom board. It does not put it on the shop calendar or the iCal feed, so a store that wants it there books an Alterations-department appointment as well. The two records do not sync.
Standing with the bride, the fitter adds each piece of work off the store's own service list: hem, bustle, bodice take-in, straps. RingUps fills in the price from the list. Type a different number for this bride and that number wins for this job only, leaving the list alone.
The manager assigns the job, or one line of it, to a named seamstress. RingUps shows each person their own list. It does not estimate how long the work will take and it does not balance the two lists for you, because it holds no hours and no capacity.
As the work progresses the job moves from intake to in progress to fitting booked to ready for pickup. RingUps keeps the board ordered by date, so the gown due on Friday is at the top of it whoever opens the screen.
Every line carries its own price, its own note and optionally its own seamstress, and a service is retired rather than deleted so a job from two years ago keeps its link to the thing it was. RingUps recomputes the job total in the database as the live sum of its lines, so the header cannot drift from the list beneath it.
The job is marked ready for pickup and the bride collects the gown. RingUps holds the alterations charge on the job and reports it from the workroom. It does not add it to her order balance, and you take payment for the alterations work outside the RingUps payments ledger. That is the constraint the module ships with, and the next section explains why it exists and what it costs you.
The workroom is the part of a bridal store that has never had a screen.
Photographed in the workroom at Cande Bridal Boutique, Kelowna, British Columbia. The room is real. The software history is that nothing has ever pointed at it.
Because the person who knows what a bustle costs is not always the person standing with the bride. The store sets the list once. Everyone picks from it, the price fills itself in, and a different number can still be typed for a bride who needs one. A service is retired rather than deleted, so a job from two years ago keeps its link to what was actually done.
Sample figures in a built screen. RingUps does not publish alterations prices and does not suggest what yours should be.
Because in RingUps the order total is load-bearing. It is what the deposit ledger holds against, what the deferred-revenue ledger recognises when the gown is delivered, and what the tax engine calculates on. An alterations charge is agreed weeks after the order is written and changes again at the second fitting. Rather than let a moving number move all three of those, the alterations charge was deliberately put outside the order total.
The consequence is not subtle and we are not going to dress it up as a feature. The payments ledger, the deposit ledger and the tax engine never see alterations money. The bride does not see it on her balance. You cannot take it through RingUps, and RingUps cannot tell you what the room earned.
What RingUps does hold is the record: what work was agreed, at what price, by whom, against which bride and which wedding date. For a store whose alterations history currently lives on sticky notes and in one person's memory, that record is the thing worth having first. The money follows the record; it has never worked the other way round.
Three pages that carry the parts of this story the workroom hands off to.
A fitting and an Alterations-department appointment are two different records in RingUps. This page explains what the appointment side does, including which booking policy fields are inert.
Appointments →Where the wedding date the workroom inherits comes from. The deadline engine computes a must-arrive-by date backward from the wedding, and the dye-lot guard blocks a purchase order at the write path.
Special orders →The workroom is one of several structural differences. That page covers the others: no API, no configuration export, and exports that contradict each other.
The comparison →No. Bridal Web Solutions has no alterations workroom. The same work is spread across appointments, per-supplier charge records and four separate reports. RingUps puts it on one screen. That is a difference in shape rather than a difference in feature count.
Fifteen minutes on your own data. Bring the binder, the sticky notes, whatever the room runs on now, and we will put a week of it into the workroom while you watch. It will be the first real week the module has held.