REVVY CPQ
REVVY CPQ is a Cloud-based enterprise grade Configuration Pricing Quoting application built on Salesforce1.
2013 @ Model N Inc. | SaaS; Enterprise Software
Background: a big scale problem & solution
When a transaction is closed, sales rep Sam always hurrays, not only for that he’s earned commission, but also for the relief from the complexity of a sale. From beginning to end a sale could easily take up months, involving teams of professionals from Knowledge Engineers to Sales Representatives.
Revvy CPQ is a web-based enterprise grade solution, including a configuration engine, pricing engine and quoting system driven by business rules and constraints, supported by a proposal management system and augmented by approval workflow systems, just as complex as most enterprise software.
I worked on most of these parts before the application is released and we were a small secret team in the company at that time.
Firstly, frame a smaller problem space
Sam is a Sales Representative, one of our user groups.
He has sales quota to meet (ultimate goal). Faster accurate quotations create more opportunities for him to achieve successful sales. Offering discount is one of the sales technics used in generating a quote for customers and it boosts up sale success rate.
In designing the quoting system, including an easy-to-use offering discounts component will make Sam’s work much happier.
To be more realistic and think in details, I made some assumption based on our personas.
Primary assumption:
He sells education software.
He interacts with customers directly, most likely he creates quotes while taking with customers.
Discounts can be applied to any goods in the quote, to any component of the goods, to the total price, and subscription price as well. Each product could have a different discount.
SECONDARY ASSUMPTION:
He has a bottom line for the discount he can offer.
The sales manager, who is the head of sales team, authorizes the bottom line. He needs to be sensitive to numbers, but may not be good at Mathematics.
Discounts cannot be stacked.
Primary assumption are the ones I have confidence on that they are mostly true. Secondary assumption are the ones I’m not very sure or I think are less important, and it did turn out that not all of them are true.
An easy-to-use “offering discount” component is fast and accurate.
Two primary goals:
Reduce the time of offering discounts.
Improve the accuracy of quotations.
Some secondary goals:
Minimize errors in pricing and quoting.
Increase average deal size.
Increase the effectiveness of sales team.
Improve customer satisfaction.
exemplars Review
Insights
Math takes time and effort.
Adding and subtracting are easier than multiplying and dividing. Instantly showing the calculated result is the easiest, however, it's more likely for customer instead of sales rep who must look into the amount of discounts.
The action of giving discount is not that time-consuming, but the decision making for how much discount to be given costs time.
Too many numbers increases mental load and easily causes errors. Preventing is equally important as recovering from errors.
While synthesizing what I’ve learned, I sketched out a few ideas on paper.
Some got thrown away, for example, slider bars, which can help Sam give discounts faster because:
he doesn’t spend extra clicks to find the correct discount number and then click to select
he doesn’t need to move hand around keyboards to type discount numbers.
However, one drawback beats these advantages: inaccuracy.
Stick with the goals, here comes the initial concept, in user’s voice.
There's more consideration in the initial design concepts.
Considering entering a discount amount is a process of decision making, I created the initial design concept with some extendability, so the user experience could be further enhanced in the future. These two additional concepts aim at 1) reducing user error and 2) assisting user in decision making.
Yet mostly, they serve the purpose of raising a discussion topic rather than a request for adding new features due to various constraint.
I might be going too far, it’s time to look back to the goal statement.
Does it make Sam’s work easier? I would say yes, it helps in the aspect of perception and decision making, so that Sam can determine a proper discount much faster. But is it a perfect solution? Definitely not. It’s time to talk to people, verify the design, its feasibility and get iterated.
How different is the final design?
And there are a lot more...
What you've seen here is a tiny part that I spent about 3 days in, including design, review, iteration and writing up annotations. Below are low-fidelity pictures of some of my work samples.
