I spend most of my time working directly with prospects and clients. What I like most about that side of the business is every day presents new and varied challenges that force me to learn and grow. And sometimes, I’m pleasantly reminded that a seemingly quaint lesson learned long ago can still be as relevant as ever.
Let’s use yesterday’s project kick-off meeting with a new client as an example. After the initial project team introductions were made, I was called upon to deliver the “RPA deep dive tech talk”. As I spouted details about screen recognition techniques, accessibility, OCR, and variance testing, etc., the Director of Procurement, let’s call him Bill, politely interrupted and said; “Joe, I’m sure this detailed technical information is important, but we didn’t buy RPA Technology, we bought an outcome. I expect you to reduce the number of man hours expended on this process by “X”, shrink the total batch processing time by “Y”, and cut exception handling by “Z”. Also, when things break, I expect you guys to detect the problem, fix it, and have us up and running in short order. How you do it…I don’t really care. You and your competitors are all good and use much of the same technologies under the hood to do the things you do. However, what drew us to your company was you folks promised to deliver the outcome we wanted, not just the technology.” I should hire Bill to do sales and marketing for us. He nailed it.
The concept of business users buying outcomes versus technology is not new. However, it’s easy for we technologists, especially when we’re passionately evangelizing new tech, to lose sight of the customer’s purchasing perspective and get caught up in the brilliance of our own creations. Just because RPA is the new shiny object, it doesn’t mean the maxims of tech selling and implementation no longer apply. Here are a few tips RPA providers should keep in mind when providing outcomes to the Bills of the world.
Respect the Audience. During the course of an engagement, which I define as all the activities ranging from sales through implementation and support, it is inevitable we will interact with different audiences. Each audience has its own needs, concerns and language. Acknowledging and respecting these variances between audiences is an important ingredient for success. We need to find out what is important to each audience and be clear regarding how the things we are doing are stepping stones to achieve the outcome sought. In a prior post, I discussed how keeping business jargon down to a minimum helps us providers understand a client’s process in terms of familiar patterns. Well, what’s good for the goose is good for the gander. Conversations with a given audience should use the language of the audience, and not that of the RPA provider where possible.
Process, Opportunities and Outcomes, not Technology. Let’s remember what the goals of these RPA projects are. We’re shooting to improve or replace an existing process or establish a new process that creates a new business opportunity. So while talking about the technology behind the scenes is unavoidable, especially with the IT team members, when communicating with the business users, it is best to couch topics in terms of processes, opportunities an outcomes. Give them the information that is important to them and leave the details for those who truly care.
Metrics Used to Measure Success are Tangible. How will we recognize success when we get there? Every RPA project should have a clearly defined set of metrics to define success. While tech metrics are fine to include (transactions per minute, bot bursting levels, etc), we should focus most of our attention on metrics that are tangible for the various audiences involved in evaluating the project’s outcome. Be careful not to include too many nebulous metrics like “improve customer satisfaction” or “increase customer acquisition”. These kinds of metrics are often more complex than they seem and cannot necessarily be attributed solely to the success of the automation.
Make it Clear We’re Not Running Away Once They’re Up and Running. One of the main reasons why RPA projects fail is poor support. By definition, RPA automations link stuff together that was not intended to be linked…and that stuff can be cranky and highly unpredictable. While we’d like to believe most production computing environments are responsibly managed, often they’re not. Even a small change to one of the systems or data sources participating in an automation can bring the whole process to a screeching halt. These work stoppages not only zap return on investment, but could become a sinkhole of opportunities lost. RPA as a service providers, in particular, must communicate its production environment responsibilities and live up to those commitments to deliver the desired outcome.
To the seasoned service provider, these tips may seem obvious. However, each new technology brings with it the potential to change the game. And while some may think this is the case with RPA, let us remember that while the tech may be new, the reasons for purchasing that tech are an old and familiar tale.
