Fluid Revenue Orchestration needs two things

Fluid revenue operations require two things to work: a good flow of data and the right data to flow. Data must flow simply this is a key problem in many systems companies maintain fragile complicated systems because they started from the wrong point. They lost their way. They forgot what matters to the board and so they shoehorn in the reporting at the end of every quarter. Many times they don't have the right data and so you wind up picking and choosing between the least bad data source. That's not going to cut it.

A good flow of data in this case means that the entire system flows seamlessly from platform to platform. For this to happen, the entire revenue flow needs to be examined from holistic perspective and you need to make the platforms work for you not compromise your data and flow to meet the needs of the platform. This seems obvious and it's shocking how many organizations do the opposite. I think it's because of organic growth, and I find that this is the biggest problem with early adopters. I think it's because they started early, long before best practices were established in the industry so they were making it up as they went. As they grew their needs, got more complex and so they bought more platforms. I know I did when I was marketing operations manager. Those platform seem to solve a discrete problem and they do it well. The problem comes in when you add in customizations. You start to add in too many layers. You solve for cases without actually weighing the value.

I would say edge cases create a significant amount of data issues. Stop and think about it. You're martech stack his own and managed by IT. Marketing is the customer. And many times when you are designing or implementing a new system, the product developers are involved. I don't know if you realize it, but developers love cases. They live for cases. As well, they should. And you know, thinking about it, IT does too because if you sell for edge cases, you eliminate a lot of problems.

But in my experience, most of those edge cases are not actually worth it. They're not quantified there's no dollar value attached to it. There's no estimate of how many use cases or cases there are. So you settle for all of them. And usually when you're trying to shoehorn that edge case solution into a platform that was designed for a specific task, you wind up adding a lot of extra data points. You might wind up with a date, time stamp, a bullion checkbox may be a list of items. Sometimes there's so many of them. They have to roll that into a custom object. And custom objects take on a life of their own.

I've seen cases where large companies have custom data objects containing 1500 fields. And there are 400 - 1000 custom objects. All of those data fields and custom objects (we're up to 600,000 fields if you use my lower estimate) sink between your CRM and your marketing automation system. Anytime any field is updated on any leader contact, that record will sync between the two systems. As you can imagine, that creates a pretty danged noisy system. And when one script or workflow is misconfigured, it might result in millions of sync actions which leads to a sync backlog, sometimes weeks of backlog.

To support this massive flow of data, cloud providers will often sell large enterprises their very own servers, maybe even the superpod or two if you need it. This is terrific business for the cloud provider, and they all throw in dedicated support engineers for a fee. As they should. Because the client has asked to support the data flow, but they didn't ask to unclog the pipes. They've asked for bigger pipes, and so the provider provides.

So let's talk about how we unplug these pipes.