Maintaining that book of past prices, who is on them, the discounts they negotiated, the feature formulation they had - its a nightmarish web of complexity even at large SaaS vendors.
I really can't imagine why. This seems like one of those self contained problems where some PricingService and a DB returns a number and deals with all the complexity internally. That seems like the logical place where you'd do A/B testing of prices and the like.
One of the companies I worked for got acquired. The CTO of the bigger company decided to personally lead a large rewrite, including:
• replacing our Wordpress blog with something custom written, including building our own database migrator (you could manually data entry our few blog posts by copy and paste)
• Replace our Google Sheets based asset tracking with an overengineered backend. The frontend was never built due to a lack of FE and design resources and everyone continued to use Google Sheets.
• choose to delete some old sections of our app that still used jQuery, angering vocal customers.
What you're missing is thaton the sales side of things, most of these price discount or variation are only really included in the quotes and not on the crm itself.
This is primarily (imho) because most companies (whether SaaS or other) start their CRM journey with the basics and only end up with some sort of CPQ or quote to cash at a later stage.