Adopting new software when quoting for business

In the ever-increasing competitive business world nowadays, we’re surrounded by more Big Data than we can remember.

Planet Earth’s population is experiencing a ‘knowledge explosion’ whereby everyone can access virtually all the information they need within a few clicks of a mouse or several taps on a phone screen.

So it stands to reason that if any company is quoting for new business, the company receiving the quote probably already knows the price of raw materials, average labor costs involved, shipping fees etc.

In essence, the prospect is likely to have a fairly accurate pre-conceived idea of the price they’re going to be offered.

Consequently, it’s more important than ever to get quotes accurate and transparent, as competitors will be waiting in the wings if a price is perceived to be too expensive or if fulfillment and delivery times aren’t to the customer’s expectations.

This is where a Configure, Price Quote (CPQ) software platform streamlines the quoting process, and a Digital Adoption Platform (DAP) helps human operators to use the CPQ software (amongst others) in the first place.

A quick IT history lesson

Companies have been producing quotes for hundreds of years before computers were invented.

Shopkeepers, accountants and salespeople would write paper ledgers of costs, add the figures together, then calculate a price for their customers using nothing more than basic mental math and a pen.

In later years, feather quills, then biro ink, were replaced by computer spreadsheets, which possess the unique ability to use pre-programmed formulae.

These formulae can work out and display a new price as soon as one cell within the whole sheet is edited.

If the cost price of producing, say, a bicycle, is calculated by adding the sum of costs of all components plus an hour’s labor for a semi-skilled worker to assemble it.

If one of the many hundreds of parts becomes more expensive to source, the spreadsheet cell containing that individual part is manually edited by a human operator.

Thus, the overall quote changes within milliseconds.

For example, if a bicycle chain normally costs $2.50 per unit including shipping from China, then economic circumstances dictate that the chain suddenly costs $3, the spreadsheet is edited to add the extra 50 cents, and the bicycle that cost $125.50 to build now costs $126.00.

But why would a company need CPQ driven by AI to deal with that? In short, it wouldn’t.

However, and this is crucial, a spreadsheet cannot warn its operators of potential incompatibilities between component parts, nor can it ‘think’ for itself of the potential consequences involved in more than just pricing issues when components change within a whole manufacturing process.

For example, rather than buying the bicycle chain that increased in price by 50 cents, it might be more economical to change suppliers for a cheaper grade of chain.

But the AI in a CPQ platform would flag that the cheaper chain would, in turn, require thinner sprockets on the bike’s gear cogs – thus necessitating a change in sprocket manufacturer.

The saving of 50 cents has now been exposed as the false economy it would have been.

It is this pre-programming of the CPQ platform with a rules-based ‘decision tree’ architecture that alerts salespeople and engineers to potential manufacturing incompatibilities before they happen.

This is a task that a spreadsheet cannot do.

It also means that a qualified engineer doesn’t have to supervise and approve every change to any manufacturing process at every instance; they only need to be involved in the initial programming of the CPQ software.

So how do we learn to use all this techy stuff?

This is where the DAP (digital adoption platform) mentioned above comes into its own.

A DAP is a piece of software that runs as a ‘learning layer’ alongside the primary platform to which it is assigned; in this case a CPQ ecosystem.

Whenever the operator of the software is unsure how to proceed, the DAP offers ‘tooltips’ to help.

Crucially however, the DAP is personalized to each individual software user on an account login basis.

This means that the DAP learns when the user has improved, so doesn’t offer the tool tips unnecessarily, which is time consuming and irritating to the user.

In the example of the CPQ / DAP integration, an engineer might be programming the CPQ’s fields at the outset.

Imagine that the bicycle chain mentioned earlier weighs, say, 1 kilogram per meter length, but the engineer is trying to input 2.2lbs per 39 inches into the field, which requires metric SI unit values.

The CPQ would anticipate that the operator was more comfortable with imperial measures and might offer to open a handy conversion screen if the operator desired it.

Once the person involved had become accustomed to the required values, the CPQ would ‘learn that the operator has learned’ and no longer offer redundant assistance.

Tech working for humans, not the other way around…

It’s probably true to say that the more utilitarian the software we use, the more complex it is by nature, and the more intimidating some people find it to adopt.

This is called ‘adoption paralysis’ – but the cure to that paralysis is offered in the DAP – it won’t be long before every piece of software with which humans interact will have an adoption assistant running at their side.

That’s got to be better for business and everyone’s mental wellbeing as our world becomes ever faster and smaller all around us.