In our recent blog post on the history of Artificial Intelligence (AI) we described the emergence in the 80s of expert systems, a form of AI which aimed to emulate the decision making ability of a human expert. At productOps, the lessons of expert systems were used in the development of a sales and order management system for a loyal client of ours.

Their existing order management system was sitting in a costly data center running Windows Server 2003 and breaking under the weight of its own complexity. The base system was deprecated and several versions behind. New products, inherited through acquisitions, brought in their own systems and were only lightly integrated. There were a number of tedious manual steps and updated pricing data was distributed by emailing Excel spreadsheets around the organization. Accountability and change management was difficult. A story told during the Discovery phase was that a large check from a customer was on the desk of a sales person for six months and had gone unnoticed.

The sales and order management system was cross functional with many touch points throughout the organization so we interviewed the sales, finance, support, product and fulfillment organizations to understand the complete business workflow and all the rules governing the sales lifecycle. The core architecture was fairly straight forward. We utilized the best practices of modern microservices, open systems and cloud deployment for our solution and json as the message payload. Our solution would sit at the intersection of their existing CRM, product catalog and financial/GL systems. We used an off-the-shelf 3rd party system for tax calculations since this system was global in nature and pricing and payments could be made in multiple currencies and the impact of the tax nexus could reflect municipality level granularity. The crux of the solution would be to model the complexity of their sales process.

System Architecture Diagram for Sales and Order Management System

As outside consultants, we can regard the business model and workflow as objective observers, which allows us to challenge existing assumptions and pricing models. The first thing we attempted to do was to simplify their sales and pricing process. Concessions were made but we were still left with a bunch of complex and somewhat non-deterministic rules. While most of the pricing models were data driven, some of the complexity reflected existing customer purchases and historical discounts. One of the most important considerations was to honor these historical pricing relationships on quotes for new products. Previously, the pricing of these quotes were ad hoc based on historical “gut” feelings and the individual relationships between the sales person and customer.

The heart of our solution would be the “pricing engine” which codified the rules of their highly specific sales and incentive models into sets of pricing rules and triggers in an SQL database. We could use the historical pricing data to represent these rules as “adjustments” and the system would incorporate existing business relationships. We could look at historical pricing for existing customers and use regression to extrapolate future pricing. This pricing engine with rules and triggers exemplifies a modern expert system. We spoke to the experts in the finance and sales organizations to get the rules and we encoded them in the pricing engine. We ran historical quotes to validate our approach and vetted these results with these experts.

We provided a quote builder web app for the user experience. One can select the billing customer and consumer from the CRM system and products from the product catalog. The “Get Quote” button would trigger the pricing engine and it would return all line item pricing, taxes and discounts based on their classification, pricing tier and the historical sales for that customer. The historical pricing along with their existing products and the discount rules acted as the knowledge base. The pricing engine would create a base price and apply the discounts as adjustments to that price. The financial/GL system could be checked to ensure that the customer was in good standing on their account. Once both parties agreed then the quote would become an order, an invoice submitted and the order would be sent to the fulfillment API for provisioning and the financial GL system for billing. Negotiation between sales and customers could be tracked in versions of the quotes.

Despite the fact that the pricing engine fulfills the criteria of an expert system combining a rule database and inference engine, I don’t recall that we ever used the expressions “expert systems” or “artificial intelligence” once during development but we did use “business logic” many times. Many of the developers on our team were too young to have experienced the heyday of expert systems. This real world example illustrates how we take for granted the expert systems that have been subsumed into the digital transformations of our clients.