Building High Quality Pricing Systems

Pricing systems, rather deceptively, can mean a lot of things. From systems that analyze pricing trends and produce analytical insights to management systems that allow users to negotiate a price point to close sales, everything falls under its umbrella. This article deals with the type of pricing systems that fall squarely in the category of finalizing a sale.

But then do we need to call them pricing systems anymore, and not simply a sales system? The answer is yes and no. It’s no if we are talking about a B2C setup where the pricing is mostly fixed and changes, if any, are pre-programmed discounts like offers, rebates, promos etc. In this scenario, the pricing portion doesn’t need a system of its own—it’s at best a small module or a block of logic in the overarching sales system. But in the B2B world where most deals are individually negotiated, ‘pricing system as an independent setup’ is a norm and a vital cog of the sales cycle.

These systems typically flow into order management systems and are sometimes built on top of them, or contained within them but often they are stand-alone and talk to the order management system through some standard interface (API). The industry term is CPQ (Configure-Price-Quote), also called pricing or quoting engines.

The crucial difference between stand-alone pricing systems and other marketing systems is the direct revenue impact they have even though all they do is deliver a singular output: a price point. Most of these systems include the process of interacting with the customers i.e. creation of a quote (negotiating/bargaining) and finally, concluding upon a mutually agreeable price. Whereas some of the others are designed to be simplistic containers of pre-negotiated and pre-approved prices—in other words databases with interfaces to upload and modify pricelists (these are the ones that are usually built on top of the order management systems or contained within them).

Sometimes you have both types of systems. Needless to say, systems that encompass so much of the pricing process are better not just from the perspective of automation or quality control, but also from a legal/compliance perspective.

Well planned/designed pricing systems incorporate the entire pricing process/cycle right from initiating a pricing discussion to applying/validating the pricing on the final orders. If something goes wrong (and some things always go wrong), customers get adversely impacted. There is manual overhead to correct the errors (credit/debit issuance etc.) and revenues get recognized incorrectly. Worse, if corners are cut, there might be legal issues, which introduce its own set of nightmares into the equation, not to mention the overall loss credibility of the organization in the eyes of the market. Which is why it’s imperative to spend a lot of time and energy in designing robust processes upfront and then apply the same rectitude to designing systems that automate said processes. Below are some guidelines that can help design high quality pricing systems:

• AVAILABILITY AND SPEED: Although purists would argue that availability or speed do not come under the purview of quality, I would argue otherwise. In the modern day of system-as-a-service, availability of the system is a mark of high quality. And so is its speed. Pricing systems where customers can place a quote and consequently order a product can and should never go down. They must be always available and operate at an acceptably high speed, wherever it’s supposed to be made available. When selecting vendors, it’s important to judge them on these parameters – in fact this parameter may even be the primary consideration in vendor selection. It’s important that their service contract contains terms for continuity of service as well enforceable penalties for unexpected disruptions. In the same vein, it’s vital that you consider the below questions to drive the selection of your pricing system vendor:
  • Are you equipped to handle X number of users concurrently?
  • Are you equipped to operate globally?
  • What are your downtime policies? How often and how long will they be scheduled for? How far in advance will we be notified?
• SECURITY AND COMPLIANCE: Pricing systems need to be secure—no one is going to argue against that. But to do so takes immense effort and planning at the design stage. Every transaction and interaction that the system enables should be mapped out and analyzed to check for potential flaws to design the correct checks into the systems. Apart from how the system is setup, auditory processes should be put in place so that there is continuous oversight during ‘runtime’ ensuring there are no breaches or unintended infractions, and any gaps/flaws that were unforeseen at the time of designing the system are caught. For instance: one of the biggest pieces of security is user-access and the central question regarding user access is which user is allowed to view what pricing and other related data, and which user is allowed to edit them? To gauge how complicated this can get consider the following; would you allow a sales user to view pricing for customers that don’t belong to her? If yes, would that be applicable for all customers, or just the ones in her geography? It only gets more complicated from there on. The best thing you could do during the design phase of your pricing system is ensure that you can edit the access rights of every data field with some level of customizability (e.g. which group of users can edit pricing and to what level). This would allow your system to be future-proof. Likewise, periodic user audits are important to keep the system and its underlying processes in check. In addition to security, one should be almost painfully cognizant of the applicable compliance laws that govern the business processes (SOX or Sarbanes-Oxley for instance). To give a simplistic example of how these rules might apply, the organization may determine that only a certain group of people may have the authority to approve pricing (such as a centralized pricing group if your company has one). Anyone else approving pricing may be in violation of the rules that are a part of corporate governance. Compliance can be tricky and often need legal inputs i.e. ensure you talk to the company lawyers when you are in the planning/design phase of pricing systems. There are other aspects of security and compliance that should be reviewed, such as:
  • What other systems do these standalone pricing systems talk to?
  • Do these other systems have the same security and compliance oversight?
  • Does the entry or exit of personnel force a system level changes in user access? Is this automated in the organization?
  • What are the policies for rogue usage? What are the punitive measures?
  • Where are all the security/compliance policies documented? Who reviews and approves them? Is the review and approval done on a regular basis?
• BUSINESS RULES FOR QUALITY ASSURANCE: When you have a system that directly impacts revenue you need a lot of checks/balances built into the system to ensure that things don’t go out of whack during execution. Take for instance a scenario where the user inputs a price, by mistake, which misses a few zeroes or even one zero, in effect, lowering the price by a factor of 10 or more. Can the system be programmed to catch these butter-fingered errors? What other such user errors does your organization need to prevent? In the case a lot of pricing processes are automated, are there scenarios where the system can’t find the right price on its own? Does it stop for human intervention when it does? There are many, many such instances where seemingly small mistakes can balloon into big, hideous problems. A computer professor of mine used to say that the strength of a system is measured by how it performs at its boundaries. In order for your system to have a good design, you should get creative with the various business scenarios that it might have to tackle. Only by mapping out various gaps in the flow of data—and testing the system’s functionality at every step where data gets modified or manipulated in some shape or form—can quality be induced into the design of the system (yes, design can often mean splitting hairs!). Pricing systems with good, built-in quality should have the following mechanisms in place:
  • Data Validation Checks: Zero checks, Rules for floors/caps, escalation mechanisms etc.
  • Exception Mechanism: Policies for how the system reacts when something seems completely incorrect (like a zero price). Does such a situation require a human to review and approve the workflow?
  • Kill Switches: Mechanisms to stop the system completely and take it out of the overall system architecture of the organization is a useful device in the times of crisis. Hopefully one never has to use them but having them is always good. Like insurance.

Bottom-line: For high quality, the design team needs to work through every potential scenario to test for potential loopholes, flaws and weaknesses. The rationale to do is to catch issues at the design stage such that you don’t have to run around in a ‘crisis-mode’ if a problem occurs when the system is up and running. At the same time, however, you can never create a perfect system which means problems will occur.

However when they do, and once you have contained the problem somewhat by putting some fix in place, the prudent thing to do is to go back and update/upgrade the design of your system. That way your system always remains current, up-to-date and high quality through its lifetime. Of course, all these changes should be documented such that the system quality is maintained regardless of personnel changes, if any. Another aspect of quality that is often ignored.

Building robust, high quality pricing systems is a painstaking process—it requires not just painstaking design, but reviews of the design by a lot of supporting functions such as legal. What is gained by good design is immeasurable compared to the costs that poorly designed systems impose on organization. Like the wise man said: “By failing to prepare, you are preparing to fail.”