Project description
We build made-to-order furniture — wardrobes, kitchens, walk-in closets — and right now every quote is put together by hand. A manager opens a spreadsheet, hunts for the right coefficients, adds up hardware and extras, and answers somewhere between half an hour and the next day. By then a good half of the enquiries have gone quiet. I want a configurator on our own site so that a visitor can assemble the item themselves and see the order of magnitude of the price before anyone picks up the phone.
The flow I have in mind: pick a model, set width, height and depth within the limits allowed for that particular model, choose the carcass and front material, the hardware and the extras — lighting, soft-close, plinth. The price recalculates on every change, without reloading the page. When a combination does not work — say, the chosen mechanism will not fit that width — the configurator says so on the spot, not after the request has already been sent. A preview image next to the controls shows the item in the selected colour, schematic is fine as long as it is recognisable.
What comes out at the end is a specification: line items, dimensions, materials, hardware and the total. One copy reaches the manager as a request, another goes to the customer by mail, and the configuration is kept under a permanent link so it can be reopened a week later or shown to a partner.
Things I am not prepared to compromise on:
— the price produced by the configurator is preliminary, and the final one is confirmed after an on-site measurement; this has to be visible on screen right next to the total, not buried in small print at the bottom;
— pricing rules, coefficients and material rates are stored so that a responsible employee can edit them from the interface without a developer, and every edit is kept in a change history: what it was, what it became, who changed it and when;
— a saved link shows the configuration and nothing else. It must never open somebody else's request and must never expose the customer's contact details;
— it has to work properly on a phone: that is where most of our enquiries come from.
The flow I have in mind: pick a model, set width, height and depth within the limits allowed for that particular model, choose the carcass and front material, the hardware and the extras — lighting, soft-close, plinth. The price recalculates on every change, without reloading the page. When a combination does not work — say, the chosen mechanism will not fit that width — the configurator says so on the spot, not after the request has already been sent. A preview image next to the controls shows the item in the selected colour, schematic is fine as long as it is recognisable.
What comes out at the end is a specification: line items, dimensions, materials, hardware and the total. One copy reaches the manager as a request, another goes to the customer by mail, and the configuration is kept under a permanent link so it can be reopened a week later or shown to a partner.
Things I am not prepared to compromise on:
— the price produced by the configurator is preliminary, and the final one is confirmed after an on-site measurement; this has to be visible on screen right next to the total, not buried in small print at the bottom;
— pricing rules, coefficients and material rates are stored so that a responsible employee can edit them from the interface without a developer, and every edit is kept in a change history: what it was, what it became, who changed it and when;
— a saved link shows the configuration and nothing else. It must never open somebody else's request and must never expose the customer's contact details;
— it has to work properly on a phone: that is where most of our enquiries come from.
Web programming Cash, Bank transfer
