Window, door and garage door colour pickers with swatches drawn from the shared palettes. Picks are optimistic in the UI and written to the canonical job record. Once the estimate is approved the colours are locked as contractual. A note on the page warns that a colour change may affect pricing.
Also called: colour selection · let the customer choose colors · trim colour picker · colour options on the quote
The customer picks window, door and garage door colours themselves
Three rows on the quote open into swatch grids from your palettes, and the customer can change their mind right up until they approve. No phone call, no email thread, no trying to remember what they said the trim was. A note on the row tells them a colour change may affect pricing and to speak to their rep, and the picks lock as contractual once the estimate is approved.
The choice survives a re-quote
Colour picks are written to the job, not to one estimate link. Re-quote the building and the customer's choice is still there and still visible on your side. When it was stored on a single revision's snapshot, exactly one customer view could see the pick and every admin view opened after the re-quote could not — which is how a trim colour gets lost between quote and order.
A colour you override comes with a written reason
If you swap a colour or mark one unavailable, the customer gets a pinned banner at the top of the quote, a warning marker on the affected row, and your typed explanation — instead of finding out at delivery. Unavailable colours are struck through in the picker and cannot be chosen, and a selection that has since become unavailable is flagged as needing a new pick rather than left sitting there.
Roof, wall, trim and wainscot colours are named on the document
The finishes chosen in the 3D builder show read-only above the hardware rows, each with a swatch and the colour name. They display rather than pick because they are design decisions already made and priced. Without them the customer sees three white hardware swatches and nothing about the Burnished Slate roof the model beside it is rendering.
- 1A pick updates local state instantly, then POSTs /api/client-portal/update-color
- 2The server validates the field is client-editable and the value exists in the palette
- 3It resolves link to (org, job) and writes to job_meta, not to the estimate snapshot
- 4A rejected or failed write rolls the swatch back and surfaces the reason
- 5Writes are refused with a clear message once the link is approved
A customer's colour picks were reachable from exactly one link and invisible to the builder. Every re-quote created a fresh link with a blank slate and the office view only ever read the newest one, so a pick made before a revision vanished and the builder ordered the wrong colour. A background refresh also overwrote the customer's choice seven to twelve seconds after they made it — the click-then-snap-back symptom — and failed saves were swallowed silently, leaving the colour on the customer's screen and nothing on the server.
- Colour picks scoped to a single estimate revision and lost on re-quote
- Optimistic UI reverting because of a background poll
- Silent write failures that split what the customer saw from what the builder had
- Colour changes after the estimate is contractual
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →