After pouring substantial resources into the careful evaluation and selection of quote-to-cash software solutions, businesses’ monetization projects can still fail if the promising technology being brought on is not properly supported in its implementation and operations. Additional capabilities may still need to be stitched in, or there may be a lack of the technical expertise required to run the system smoothly. Furthermore, monetization transformations take time and touch every aspect of an organization, so misalignment between the expectations of departments or a poorly paced plan can make the process painful and tedious. To learn more about the most common issues that arise in these ventures as well as how to prepare for and overcome them, we invited Brian Reid, Director of Business Development and Strategic Alliances at RESPEC, to speak with MGI Research analyst Andrew Dailey at the 2021 Monetize Forum.
Key Issues
How can systems integrators help bridge gaps between technology solutions and companies’ operating processes?
What errors and oversights are most common in monetization projects?
What kinds of operational support affect the TCO of a technology solution?
Guest Profile
Brian joined RESPEC in 2018 and is the keeper of its Monetization strategy, focusing on building strategic partnerships to expand the monetization practice. He previously spent 10 years in Oracle’s Communications Global Business Unit, leading the sales team in North America for Enterprise Billing and Revenue Management. His 30 years in telco include time with companies like Lucent Technologies, Avaya, and Sylantro Systems.
Andrew Dailey
This is Andrew Dailey of MGI Research, and welcome to our next session, “Ensuring Project Success: A View from the Trenches.” Organizations spend an enormous amount of time, effort, and money evaluating software solutions that are part of their overall quote-to-cash and monetization capabilities. What’s often overlooked is what happens once the selection process is completed. At that point, your monetization journey is really only beginning. To discuss what it takes to ensure success for both the project and the ongoing operation of that monetization journey, I’m joined by someone with over 20 years of experience helping organizations stay on time and on budget in these challenging projects. I’m delighted to welcome Brian Reid of RESPEC to the Monetize Forum stage.
Brian Reid
Hi, Andrew. It’s good to see and talk to you.
Andrew Dailey
Tell us a little bit about RESPEC and how you’re helping companies across the whole spectrum of agile monetization.
Brian Reid
At RESPEC, we joke internally that we’re a 50-year-old company that nobody has really ever heard of. I think for a lot of the audience going to our website, the first thing they’ll probably ask themselves is, “What is a company that does mining and natural resources doing with billing?” Well, RESPEC is a 50-year-old science, engineering, and software consulting firm—so interdisciplinary practices. Amongst those is an almost 25-year-old billing practice and now, of course, agile monetization.
We’ve been helping customers select, implement, and operate those systems since 1996. If you remember back then, the Telecommunications Act was passed, and there was deregulation and telcos popping up everywhere. There was a lot of need for what we called “complex billing” at the time, which has now evolved into agile monetization. We started working with a company called Portal Software (which we now know as Oracle Billing and Revenue Management), and for the last 24-plus years, we’ve been helping customers implement and operate their complex systems.
Andrew Dailey
There are dozens of systems integrators branding themselves as monetization and quote-to-cash specialists. It’s a rich and vibrant market. In addition to the history of your firm, what would you say really differentiates RESPEC?
Brian Reid
The history certainly is a big part of it. Having the experience and seeing virtually everything there is to see in one of these projects definitely stands out. We’ve worked with companies of all sizes—large Fortune 500s like Equifax, CenturyLink, and Charter, all the way down to startups, joint ventures, and many telcos. We work with enterprise and high-tech companies like Cisco and most recently Cloudflare. Dell is another one that stands out. We really work across the board with very small companies and very large companies.
Over all these years, we’ve focused on the domain and trying to establish the best practices for that domain, creating repeatable solutions for it, and understanding that technology always changes. It certainly has since 1996, and people are seeing a real rebirth or renaissance over the last half dozen years with a lot of new technology. However, at the end of the day, we feel strongly that the domain stays the same. We adapt to the technology, but we help customers understand how to apply that technology across the order-to-cash domain with a special emphasis on monetization.
Secondly, our technical depth sets us apart. Many companies in this area of professional services focus on the business flow, product definition, and things like that. These are all very important, and we certainly do that, but over the years, we’ve also established real technical depth in the technology as it has evolved, as I mentioned. We may talk a little later about the things that encompass that domain when we talk about billing specifically. There are a lot of things that touch that, so having that technical depth is very important for us. We treat our technology partners as customers as well. They’re our clients. So, we really have two clients in this: our technology partners and our end-user clients, and we work in the middle of those two. I think that sets us apart as well.
Andrew Dailey
One of the issues that often comes up is a kind of gap that sometimes exists between business processes and technology. You touched on this, but how do you help bridge that gap in those challenges between the technology piece, the product piece, and what’s happening from a process flow?
Brian Reid
As I mentioned, over the years, we’ve seen that every implementation is unique, but they also share a lot of commonalities. What we see are a lot of common solution gaps that aren’t necessarily addressed within a particular platform. Let’s focus on billing for a second. In almost every deployment we’ve ever been involved with in the last 25 years, the customer requires capabilities that are often outside the perimeter of the billing system alone. We can look at self-care as an example. I remember maybe six months ago, your team at MGI hosted a webinar, and part of it was a study revealing that 30–50% of all calls into a customer center for production services are about billing.
If you can reduce your billing questions, you can significantly reduce your overall operational costs for that service. Having a self-care type of portal is one way to do that. What the customer typically needs in their self-care portal is not really what the billing system delivers out of the box, so we supply a platform that is system-agnostic and provides a set of self-care portals that customers can then modify and fit into their own overall UX strategy. That’s one example. I can say the same thing for areas like payments, invoicing, mediation, and order orchestration. These are all things that come up when an enterprise gets into an implementation. They might go to their billing supplier and say, “Hey, do we do this?” Often, the billing supplier sort of draws this box around what they do, and they don’t really do anything outside of that. That’s where we come in. We can help fill in those areas of solution gaps that might not otherwise be available in the billing system. We see that across the whole order-to-cash spectrum as well.
As I mentioned before, another thing that sets us apart is our relationships with our suppliers. We focus on helping them grow and scale their businesses. In particular, with the SaaS suppliers that we see a lot of today, their whole valuation is predicated on ARR. Often, the professional services function isn’t seen as a profit center, and it sort of drags on their ARR margins. When we come in, we help them scale that business so they can address more customers and more market and achieve not only improved customer service but also better margins on delivering their service.
Andrew Dailey
Let’s talk specifically about monetization projects versus the typical technology or common business application kind of projects. Within that, where do you see companies typically underinvest? In what aspects of these projects do they tend to overlook things that end up putting the project at risk?
Brian Reid
Monetization projects are very unique among other projects that an enterprise is going to undertake in that they really touch every aspect of your business and how you envision your customers are consuming your products. They involve designing products, coming up with bundles, quoting them, provisioning them, delivering them, rating services in real-time—all the way through taxation and revenue recognition. That’s a big, broad spectrum that a monetization project will touch. Clearly, there are different degrees of that, depending on how complex and how big the enterprise is. That said, even in what we might consider simple billing replacement projects, they do still touch all of those aspects. That’s very important.
In considering things that are overlooked, underinvested in, and that show up as common mistakes, one of the things that we see happen frequently is a misalignment of how the business wants to define and create products and how the IT team typically thinks they’re going to bill for them. Sometimes, they’ll create a situation where a product or marketing person has been defining a product to their customers, but then you can’t bill for it or you have to do some special tricks to bill for it. I think that’s an area of emphasis with our customers—to help them understand that before you make your selection, you need to know what your product is, how you envision your customers consuming your products, and how that whole monetization stream will support that process. That’s certainly key.
There are two other things I’ll mention. In the category of things overlooked, one that probably comes up most frequently at implementation time is product catalog. Oftentimes, they’ll go through a selection process. Let’s say a customer chooses a billing system. Maybe they haven’t yet chosen a CPQ system, so they have their CRM, they’ve got their financial system, and now they ask, “Okay, how do we do this?” One of the first questions we ask is, “Well, who owns the product catalog?” I think that’s an area where, early on in the process, customers can really benefit from making sure they make a decision. I tell my customers all the time that, philosophically, there is no right or wrong way to do it. The product catalog can live almost anywhere, and oftentimes it does. However, I also tell them there is a right and wrong choice for you, so let’s figure out what that looks like early on—before you get started, before you make selections, before you architect. That’s something we see on the overlooked side.
On the underinvestment side, clearly the issue is operations. Far and away, that’s the thing we see our customers not investing enough in early on. As you mentioned, enterprises are spending millions of dollars, and they seem to have a sort of inherent understanding of what it takes to go through the selection process. They research the market (hopefully, they’re working with MGI to do that), they’re going to issue an RFP, they might do a bake-off, and then they’ll run their implementation. What they tend to forget is how they’re going to operate, considering that they’re going to be living with this solution for the next decade or more. It can often come as a big surprise, especially for smaller companies who maybe haven’t managed complex systems like this in-house. There can be sticker shock, and it can be a real eye-opener for them in terms of long-term success. So, we spend quite a bit of time with our customers understanding that part.
Andrew Dailey
Yes, we absolutely see that. One of the benefits of many of the cloud-based solutions is that they can be sold directly to the business, and they can be used by business users and finance teams directly. What you sometimes see, though, is exactly what you described. They overlook the fact that, in terms of doing upgrades, support, and any kind of changes to the system, you really need to have that IT discipline in operations. Often, the business folks don’t necessarily have that experience.
Brian Reid
Yes, we’re working with one of our larger enterprise customers right now on this very thing. They’ve done a great job in understanding what their feature and functionality requirements are, so they were getting ready to issue the RFP. We said, “Let’s take a step back and look at operation. How are you going to run with this operation over the long-term?” They ended up pulling their RFP back and saying, “Okay, let’s give it a couple of weeks because we want to make sure that operationally, the systems we select are going to support our business. What do we need from the help desk, from data mining, et cetera?”
Andrew Dailey
One of the things you mentioned earlier that I want to talk about is the whole issue of mediation, which is a telco term but one that’s really gaining currency in almost every project and industry that we see. It’s really the management and enrichment of data. In our research, we often talk about projects failing because of data-related problems. Is that something you see? How do you help organizations that have data quality or data management problems?
Brian Reid
Yes, that’s something we see. As you said, mediation is something that is gaining more currency in the enterprise; it’s always been a telco capability. We’re now taking that telco thought process and making enterprise customers aware of how to handle mediation, especially as it relates to usage-based pricing models, which are becoming more and more common. Over the years, we’ve developed some mediation capabilities. We don’t sell products; we wouldn’t want to compete with the DigitalRoutes of the world that are doing a great job. With our customers, we focus on the understanding of where their data comes from, how they can organize it, and how they want to bill for it. Maybe there’s other sales analytics data that can come out of that too that you might not even use for billing but could use for ongoing sales analytics. That’s definitely an area where we’re seeing more and more activity with our customers these days. In the enterprise about four years ago, it was very rare to see a mediation usage. Now, we probably see mediation come up about 40–50% of the time.
Andrew Dailey
Let’s talk a little bit about post going live. There’s an implementation project, but that’s really just the beginning of the journey. What do you guys do? What kind of services do you bring to help people in the ongoing operations and success of their other projects?
Brian Reid
Yes, like I mentioned before, one of the things we try to do with customers who are just getting started in the game is to understand what those impacts are. I’ll give you a few examples. You mentioned data, and data is a good one, especially with SaaS. Back in the older model, everything was on-premise. You owned your data, oversaw it, had access to it, and could do whatever you wanted with it. That’s not always the case with SaaS, so you need to make sure you understand if your SaaS provider gives you access to it. If so, how? Is there a special technology that you need to use? Are there additional fees that are required to do that? It’s going to add to your total cost of ownership over time if you have to invest in other things simply to get the data out of it. That’s one example.
Another one I briefly already mentioned is help desk. The SaaS providers do a great job of running the operating system, the database, and the application in patches, but a lot of customers want to take advantage of some of the great features of these monetization platforms. They don’t know how to do a simple thing like creating a new pricing plan. So, who do they call when they do that, and is there an additional cost for that? Again, understanding what the costs are and what burden you’re going to have to carry as a billing operations manager in order to run this platform is key. Those are examples of areas that we work on with our customers, and there are dozens if not hundreds of scenarios that we walk them through.
Andrew Dailey
We have a minute left, so if you could give one piece of unvarnished advice, something that you always wished you could say to a prospect but were never able to, what would that be?
Brian Reid
There are a lot, but I’ll pick one. In our virtual booth, we also have our “Seven Tips for Successful Monetization,” so I would encourage people to look at that—it hits some more of those silver bullets. For now, if I had a customer contemplating a monetization or order-to-revenue type of transformation, what I would want to tell them is to not just understand but embrace early on that this is a multi-phase, multi-faceted project. As I mentioned before, it’s going to touch virtually everything in your organization. Don’t try to do too much at once. If you’re doing CPQ billing, order orchestration, or service management, find those swim lanes and let them operate individually where they need to. Don’t try to mix or cross streams; understand that each one is going to have a set of deliverables in and of itself. So, don’t try to do it all at once. Additionally, design wins into your project early on. The wins are important to gain momentum, so plan and design for those early wins. Don’t wait 18 months before you roll it out, flip the switch, and voila—you have a new billing system. People will get frustrated, and it will be hard to manage expectations as time goes on. Therefore, plan for those early wins and plan for successive wins, so you continue momentum throughout the project.
Andrew Dailey
That’s great advice, Brian. I know you’re going to be around for the networking, so I would encourage everyone to reach out. I’m sure you’d be happy to share experiences and connect with folks. With that, I’d like to thank everyone for their time, and thank you, Brian, for joining us today.
Brian Reid
Thank you, Andrew.
