In my experience, there are two key things that affect organic end user adoption: convention & delivered value.
I have seen many technically elegant CPQ implementations that have suffered low user adoption because the convention adopted is unfamiliar to the end users.
For example, imagine a project led by the IT department for laptop sales. The approach is often to build the quote by selecting the necessary components that will make up the laptop. This will produce an output that will support technical integrations very well (product master databases, inventory systems, fulfilment systems, etc). However, it takes an approach that is not usual for a sales organisation.
Although such an approach may be good for supporting the rest of the organisation, it may (and most likely will) put off the sales organisation from adopting the tool. It requires them to think differently from how they usually do and puts a greater burden on them to make selections when they don’t want to or, usually, don’t need to.
The converse is also true – in projects where the sales organisation leads the implementation, the solution is designed to be clean and very user friendly. However, implementation decisions that lead to the solution often struggle to fit into the data and process architectures which support other functions in the organisation.
The job of the CPQ implementer is to work with the teams in order to come up with a solution that works for both situations – the sales/customer facing and the technical/internal facing. The client organisation must set aside sufficient resources to manage the change that will come with these compromises to ensure long-term project success.
- On February 29, 2016