How do you create a truly photo realistic visual CPQ (configure, price, quote) system that allows consumers to visualise what they are actually buying, signing up for, before actually placing that expensive order? The type of products I’m talking about are large ticket purchases – kitchens, bathrooms, furniture, wardrobes etc. Similar to buying a car using a configurator but many more variants.
Well it starts with a spreadsheet..
Take an ordinary spreadsheet (Excel, Google Sheet) and enter some data (quite a lot actually) – product, prices and colours. You can also add in a categorisation of each product giving it a hierarchy (we’ll come onto that again a bit later).
Add in key information about the product – lets use a house as an example – house type, floor, rooms, layouts and zones within each property.
All pretty standard stuff so far!
Do this for however many products there are 100 up to tens of thousands – doesn’t matter. The critical part of this is making sure the information entered is in the correct format – establish a data dictionary for the information – and is consistent. Don’t forget the old adage – crap data in, crap data out, and this is so true.
Now we start some magic….
Take that dreary, mundane spreadsheet and import it into a relational SQL database. You may have had to prepare the database beforehand, you’ll have to come up with your own design for this bit based on the end output.
So far nothing too out there or hard, nothing new, nothing revolutionary.
The data is now safely in the SQL database and nicely sorted and waiting. But wait there was a product that has been discontinued, do we upload the whole spreadsheet again? No we use a friendly interface to directly access the live data and we can edit it – so we set that product as disabled, not deleted, – means it wont be available in the final output.
The spreadsheet import has created from the simple spreadsheet:
- House type
- Rooms on each floor
- Layouts within each room
- Zones within each layout within each room
And within this added:
- Each product
- Linked to each house type
- Linked to each floor
- Linked to each room
- Linked to each layout
- Linked to each zone
Now that is a nicely structured set of data, but what do we do with it now, what purpose does it serve, have we spent weeks pulling the data together, how is it commercially viable, how do we get to it – apart from the pretty UI?
Let me explain the original project objectives….
A house builder wanted to allow its customers to configure a house (similar to a car configurator), give them total control for their choices, reducing the reliance on sales office staff to help customers choose using the kitchen, tile, flooring – they wanted the customers to SEE their kitchen with THEIR choices in a photorealistic view, with a price given, allow the customer to create many different configurations to help them better customise their “homes”.
So we had to start with product data and work out how we get that into a configurator system served over the internet in real time on tablets, laptops, and desktops – more on that in a later article.
Want to know more: