When my company started selling our Ratchet-X RPA platform twelve years ago (long before RPA had a name), we had a tough time marketing the solution for the following reasons; a) RPA is a technology that every organization can use, but apparently, it is very difficult to market to, well, everybody, and b) prospects had become so accustomed to software applications not communicating with each other, they couldn’t understand how what we were proposing was possible. We thought we were clever branding our solution as a “desktop application integration platform”, but that only left prospects asking; “Great, what the heck is that?”
Although the term RPA has helped describe what it is we do, we need to appreciate the term is still foreign to most prospects (at least the prospects we encounter). Further, those who are familiar with RPA have vastly different understandings of the term as we vendors, predictably, have tried try to make RPA mean all things to all people.
So what’s the point? Well, despite the fact analysts tell us RPA is poised for enormous growth, and RPA vendors’ sales are keeping their boards quite happy, we still find ourselves doing a lot of evangelizing and educating. Though obvious to those of us who live in the RPA bubble, understanding what RPA does, the cost savings it can yield, the new business opportunities it enables organizations to seize, and why it is frequently preferred over traditional integration methods, is a bit more elusive for prospects just beginning to get their minds around the concept.
Relevant Point Solutions
Evangelizing and selling RPA successfully, be it internally within your organization, as an external consultant, or as an RPA vendor, all comes down to making RPA relevant to the user. While this may seem obvious, this simple sales technique often takes a backseat when technologists talk to users. All too often, we get caught up in how a cool technology works rather than how can benefit the user. And the most effective way of communicating those benefits is to speak the user’s language. We need to frame the RPA conversation in terms the user can viscerally understand.
To underscore this point, let’s look at the evolving RPA conversation I alluded to above. When I would tell a prospect we sell a desktop application integration platform, most folks were nonplussed because they did not know what that really meant. Then I would tell them that our solution allows them to add new features to their existing applications without having to modify those applications in any way. Well, we’re getting warmer because the prospect is now intrigued, but is still unclear as to how that benefits him. Then I would home in on a very specific and relevant use case. For example, our solution will enable users via a single click, to retrieve documents from their document management system directly from within a specific record in their CRM system. That is when the power of the solution hit home because the prospect knew he had two hundred customer service representatives who repeat this process thousands of times per day. If we could really reduce a process that normally takes thirty to sixty seconds each time it is performed down to 5 seconds with a single click, that would be a huge productivity boost. The sale just got a lot easier because we were proposing a solution to a specific pain point versus a technology.
So while we are still evangelizing and educating, when dealing with end users, we need to get out of the clouds and come down to ground level. No doubt, RPA using organizations need to understand how the technology works and what are the technical requirements. However, that is not what we should lead with. The quickest way to get an organization started with RPA is to frame the discussion in terms of point solutions rather than an enterprise-wide automation platform. If we communicate that message in terms users can understand and then deliver on our promises, it won’t be long before the user asks; “Where else can we use RPA in our organization?”.