Archive for the ‘Attach Pattern Web Service’ Category

h1

Don’t waste time on a poor CPQ User Experience

May 18, 2020

The configure element of Configure Price Quote (CPQ) consists of combining parts available to create a product that will operate.  The more complex the component combinations can be for a product, the more highly configurable it is. 

There are several approaches to configuration which affect the User Experience (UX) in a CPQ application.  Each has its benefits for different types of users; however, being performant is critical to the application’s success.

Free flow, including accordian

A user can add any option or part to a quotation or basket. Errors are permitted, e.g. overpopulation, but the system generates warnings alerting the user that the errors need to be corrected. Many of channelcentral’s CPQ applications use this approach.

Free flow is ideal for regular users that have some knowledge of the products and options, or technical information is readily available.

Always correct

The configuration system constrains options so that anything that a user adds is functional.  As a user adds more options, the remaining choices are restricted further. Some of channelcentral’s light eCommerce customers adopt this approach, using boost! and APWS.

Always correct is ideal if a user is infrequent or has limited knowledge of products, to simplify the process of selecting parts.

Pre-Qualification

The user is asked a set of questions up-front, and the configuration system limits options and therefore, complexity based on the responses.

Pre-Qualification is ideal if a user has no real knowledge of products and options available but does know clearly, the solution they require in purchasing a product.

Forrester has recently announced a top trend for 2020 will be an increase in ‘self-service for end-to-end customer journey‘, including customer-facing CPQ solutions for B2B buyers. 1  channelcentral designs all its CPQ and eCommerce applications with users in mind, so that users can self-serve. 

Is a poorly designed performant User Interface equally bad to ‘egg-timer time’?  Present the user with a form that takes one second to load but 30 minutes to complete is worse than something that takes a few seconds to load on each click but only takes 10 minutes to complete.

Our CPQ applications have not only complexity, but also a lot of dynamic data (notably price/stock), that enables them to generate complex configurations.   So, we are refactoring (altering the code architecture) to make them as performant as possible for the best possible UX. By optimizing the architecture and the UX design, the future releases of our CPQ applications will enjoy the best of both worlds.

1 Top CRM Trends for 2020, Forrester blog by Kate Leggett, Vice President, Principal Analyst, 11 February 2020

Watch the video summary here:

h1

Optimizing CPQ Applications

September 9, 2019

User experience covers a variety of topics. A poorly designed user flow or a badly designed screen layout is irritating, but nothing gets users more frustrated than application latency. On initial launch, a CPQ application can have really good performance, but over time it degrades: application optimization is not a single task, it’s more like a maintenance contract! CPQ applications spawn data, valuable data and simply archiving that

At channelcentral we used to speak about a four second rule. It’s an arbitrary number, but we believed that if a user didn’t see a result on click within four seconds they’d click again as the assumption is they didn’t click correctly OR the application needs a reminder. Today: four seconds needs to be nearer one second – user expectations are higher due in part to the Smartphone experience.

channelcentral recently undertook an architectural review of the applications that run in its “CMS” framework. One finding was that a lot of latency was caused by “Web Services” where applications pull in data to enrich the content with time sensitive data (notably price and inventory). Users were experiencing wait times of between four and 10 seconds and that was clearly unacceptable.

The Development Team looked at Microservices (MSA: Micro Service Architecture) as a potential solution to latency caused by data requests. Once deployed, application performance improved by up to 10X.

Moving from monolithic to modular has other benefits in terms of deployment, fault detection and code maintenance. There are some ‘cons’ with Microservices, but improving performance to that extent makes it an architecture we’re investing in.

Watch summary video here: