“Design must reflect the practical and aesthetic in business but above all good design must primarily serve people.” Thomas J. Watson
In Part 1 of this series we left you with the above thought, and we started to look at how CPQ design affects people from different business functions in different ways. Now lets look at this in some more detail.
Consider these communities:-
Salespeople – need an unobtrusive system that enhances their chances with a prospect. They need a quick answer to the questions “What have I got to sell?” and “How much can I sell it for?” Salespeople are an expensive resource so fewer hours spent on data entry equals more productivity i.e. time to sell.
A CPQ system should ask a salesperson to enter data only when they are the sole source of this information, or the best-placed to capture it, e.g. information about clients exact needs, specific product features or service levels that have been discussed with the customer. Other detail e.g. exact customer addresses, current contracts or detailed service descriptions may be provided more cost-effectively elsewhere better still if it can be integrated and automated. Alternatively, perhaps the information has to be provided by sales, but maybe not at the same time that a speculative quote is being generated.
Speed is of the essence. Quick answers, efficient approvals and automatic generation of professional documentation are required reducing valuable selling time being spent in front of a complex screen.
Technical advisory teams – here the detail can be critical, and in many cases its where a deal can turn from profit to loss, or from achievable to impossible. If your CPQ system involves experts contributions to a deal then you need to clearly think through the timing of their provision of information. What do they need to know before they can enhance the detail of a deal? Which of their choices will make an impact on the financials of the deal? Which affect the deliverability and which are just about dotting ‘i’s and crossing ‘t’s? How do you balance the need for early information entry to help the deal along with the chance of something changing? For these teams the drivers are different, and often the personality types involved too. A good CPQ design provides a workflow and UX that takes this into account.
Approvers – again a need for detail is obvious, but we also need to ask “What information is truly needed to make a decision?”.
Some data points are absolutely necessary e.g. margin for an FD, and some are contextual information like customer sectors or price levels of existing contracts. We don’t need to give every piece of information to every approver as these people are often in senior positions and are deluged daily with data. Instead, present the optimum amount of data, structured with clarity to make their touchpoint with your system a pleasure. Failure to do so can have dire consequences we have seen systems grind to a halt because approvers delay making their decisions and quotes are left in limbo.
Think through the logic of approval chains. Should these be serial or parallel? In too many organisations we see a stand-off where no approver will invest time analysing a deal if all other approvals are not in place. The valid fear is of wasted time if they scrutinise first, but then another department rejects the quote.
Take the time before implementation to talk to the approvers, and the stakeholders whose day-to-day operations will be affected by your choices. Customers need quick answers. Cumbersome approval logic that tries to please all the approvers, all the time, can be a recipe for disaster.
Back-Office / Order Entry teams – these background teams keep an organisation working and make the business happen, so we need to build systems that are efficient for them too. This is true whether you have integration to downstream ERP / back-office systems or in organisations where everything is manual.
Perhaps there is more tolerance within these teams of the functional over the aesthetic, but often this is due to a legacy of 20th Century systems where capabilities were limited. We like to challenge this norm. Back-office UX can be the hardest to get right, so we must allow sufficient time and resource to plan for this.
Thousands of transactions can flow through a CPQ system daily and back-office teams need to be able to get to the information they need to keep transactions flowing. They must be able to populate deal details easily when they have access to that information. Remember that teams in the back-office need to be enabled by a system, not to be fighting against it.
So, in this, the second part of our three-part Design series, we’ve looked through the eyes of some key different users.
Let me know in the comments if there are other communities that you’ve had to design for. Part 3 will conclude by focusing on the most important stakeholder the customer. We will look at their point of view and conclude with some thoughts on how to plan for success in UX design.
