With a couple years under our belt, we have enough scars and lessons learned to put forth a list of things to consider whenbuilding a configured product.Whilst reading is great, we would prefer to show you in a demonstration, but please read on.
Consider the End User
Building a configured product is about making someone else’s life a little easier…
Guide the User
Consider the flow of the journey you are taking the user on and put yourself in their shoes. Most importantly remember that they will not have the same level of expertise (hence you are using a configuration tool to help them). Use Information messages, sales guidance and business rules to inform the user on the choices they have and the impact of those choices.
We wrote an earlier blog on this, but it is pretty clear that too much choice confuses people. Limit choice to the most expected options. If requests come in for options that are not included, they are easy to add in servicePath with some drag and drop.
Allow for No Choice
Perhaps this should be part of the point above, but consider the customer may not want the choice that is made. It is best to use a Label Item to define that a specific configuration has not been requested. See next point.
Tell the Customer What they Didn’t Buy
In some instances it is important to tell the Customer what they did not purchase as what they did. Consider when a customer does not request backup, then the server dies, then they say “well, it doesn’t say you are not backing the server up”. In those situations it is better to use Quote Syntax to say “No Backup Selected”… this also leaves opportunity for an upsell in the future.
Signal Versus Noise
Not all configuration information needs to be communicated to the customer. Too much information will take focus away from the more important configuration items within the service. For example, if a customer purchases a physical server, is it important to mention that it includes a rack mounting kit… probably not.
Less Free Text
Free text offers the most flexibility, but also allows for the most variance and possibility for user error. If you know a defined set of options then use a choice group. This will make the users life easier and result in a more consistent output that will make service delivery much happier.
The following are general guidance around configuration:
It is really important to have a pre-selected set of choices that is a sellable, deliverable and profitable configured product. Starting with a product that doesn’t work puts more effort on the end user building the quote and creates more opportunity for error. EXECUTION: On running the configuration wizard, will the product be sellable, deliverable and profitable.
Generic to Specific
People have a tendency to think from more general aspects of a service to the most specific – configurators should do the same. Why? Generic choices may impact deeper and more specific choices through the configuration journey. Consider the example of a virtual server where you would want to know the type of operating system (general) before defining what applications (Specific) will be available. e.g. Linux server will allow for NGINX web server.
Configuration Doesn’t Happen in One Direction
It is easier to think of a configuration journey in one direction, but that is not really practical. When building a configurator, consider the user may jump around and making choices in a non-linear fashion. Our rules must therefore account for this – the best way is to ensure we have the alternate condition (ELSE IF) accounted for.
Don’t be Over-prescriptive
The rules engine in servicePath is quite powerful and we found in the beginning to implement the most concrete and prescriptive rules we could, cause we could. This was wrong – sales does not work this way. We should guide the user, but also depend on the expertise in the business to make some of the right choices.
The Technical Stuff
Maximise Screen Real-Estate
With our Section Groups you can have multiple configuration groups on a single screen. This will allow you to present more choices to the user at one time providing a clearer picture of the journey they are on.
Without a doubt, the first configured product that you build can be optimised by removing options/choices and changing the journey you take the user on. After you build your first configured product, use the preview configurator function and demonstrate it – we are very confident that peer will offer quite few ways to improve the speed by minimising mouse clicks.
Bite Size Business Rules
Whilst you could build larger business rules, why manage the complexity. As we use event-driven business rules, rules can be smaller, more readable, easier to explain and train others to manage.
With multiple product managers working on configured products it is important to have a set of standards that are agreed by all. These may include:
- Group structure
- Label item naming
- Quote Syntax
- Use of information messages
- Naming of business rules
Building Your First Configured Product
We have worked hard to define a standard methodology to help you build and maintain configured products:
Know the items you need in the configuration journey – items like vCPU, Memory. Storage, Operating Systems, Applications, Monitoring, Management, etc.
Define a rational structure that will guide the user through the configuration journey – groups like Resources, OS and Applications, Additional Services. Add your items.
Map out your logic, but always start with the default configuration. What is visible, recommended, required and what options require quantity to be enabled.
The rules will drive the logic to ensure a working configuration – generic to specific should be a guiding principle here… and keep rules small and bite-sized.
Probably the most important part. Information messages, group descriptions and product tags ensure there is well rounded information to the User and the Customer.
We have lots more where this came from – reach out and we can show you some working examples on our demonstration environment.