How ElectroNeek Has Differentiated Itself From Other Robotic Process Automation Companies

Interested in my latest Forbes stories? Subscribe to my mailing list, Founder to Founder: f2f.substack.com.

Modern corporations perform more of their operations digitally. Great volumes of data are still collected, recorded, and stored in spreadsheets and databases manually. Dmitry Karpov, 33, Sergey Yudovskiy, 33, and Mikhail Rozhin, 33, believe with robotic process automation (RPA), businesses can increase employee productivity by eliminating these mundane tasks, starting ElectroNeek as a result. ElectroNeek is an RPA startup developing digital assistants and digitized workflows for startups and information technology (IT) teams. The startup is currently based in San Francisco, California.

Frederick Daso: Why was UiPath heavily focused on selling to enterprises instead of SMBs developer teams?

Sergey Yudovskiy, Dmitry Karpov, and Mikhail Rozhin: UiPath and other industry pioneers build their initial go-to-market strategy on automation of jobs that big corporations had been already outsourcing to low-cost locations. Corporate clients already had process maps in places, for instance, well-documented Accounts Payable processing. RPA pioneers came with a value proposition of quicker and cheaper execution, eliminating the need for the outsourced position. Such positions, where mostly 100% of labor can be automated, merely exist outside of big corporations. And, of course, Fortune 500 companies have an excellent tolerance to experimenting with new tech and budgets to maintain the automation solutions. And, after all, they have access to knowledge of the most experienced tech consultants from reputable global firms. Only in 2019, we started to see small consulting firms with excellent RPA expertise to lead complex implementation projects. In 2016-2017 there has been none.  

Daso: What were some of the unique challenges in implementing UiPath that you seek to eliminate with ElectroNeek?

Yudovskiy, Karpov, and Rozhin: With UiPath, it was easy to start an 'entry' project for a client, but getting from a few bots to scale was affordable only to organizations that decided to make a significant bet on the RPA. Because of UiPath's business model, clients were required to acquire additional pricy orchestration features that enable bot scheduling, sequencing, and ability to run unattended (autonomous bots on virtual machines) automation. 

Making cloud orchestration free essential part of our ElectroNeek Enterprise platform was on a product roadmap on day 1, and we finally released it before joining Y Combinator. 

Daso: What are the core, canonical problems that engineers face with implementing RPA tools and other automation processes?

Yudovskiy, Karpov, and Rozhin: The most critical and essential RPA automation steps are steps that involve GUI automation. For instance, one automates taking data from LinkedIn or a government website to a spreadsheet. Spreadsheet integration is an easy task due to standard functions/APIs. Still, the web portal will require telling robots how to identify GUI elements like buttons and what to do with them (clicking or completing a form). 

A canonical RPA problem is how does one reprogram the bot when the web or legacy app interface changes? Just a small tweak to a web interface will crash most bots! An RPA developer that works with the other vendors needs to audit all automation steps that involve working with changed interface elements and rework the logic. It's a very time and effort-consuming process that reduces the automation value.  

To solve it, we came up with a concept of 'Voodoo Interface,' patent-pending way of creating mockup interfaces that mimic real GUI of the environment where the automation is performed. Our bots then work with these mockups instead of with the actual interfaces, and the only place where the changes should be made when real GUI changes are these mockups. This dramatically reduces workflow maintenance needs.  

Daso: If you're letting your customers automate as many processes as they want, then where is the primary price that they are paying? 

Yudovskiy, Karpov, and Rozhin: We charge a fixed price for the whole automation suite, which depends on enabled advanced features like visual table editor and number of IT professionals who develop workflows on the platform. This model makes sense for small companies that have only a few developers (they pay less) and for large corporations (who may have hundreds of developers but many thousands of potential automation targets). It's a 'classic' IDE model standard for IT professionals, and it democratizes access to RPA for both small and large businesses. Eventually, current RPA unicorns would need to change their business models, but they can't do it now without sacrificing their significant revenues from corporate clients.  

Daso: Are these RPA solutions tailor-made for each company? Or do they get access to a suite of tools so they can automate their processes? What drives mass adoption at scale among devs.?

Yudovskiy, Karpov, and Rozhin: The platform consists of standard visual programming and coding tools, information, and infrastructure management modules, all brought together in one cloud-based customer account. Some clients build reusable customizations on their own, but we are not big believers in trading of reusable workflows on a marketplace. Trading customized features, though, could be exciting in the long run. 

Yudovskiy, Karpov, and Rozhin: Adoption at scale among developers is driven by having a good workflow/code structure and visual programming tools that shortcut heavy-lifting development steps (like extracting data from specific scanned files). Also, building capable admin and information management between developers and end-users (when you don't have consultants to facilitate process sourcing and finding processes for RPA is not an IT professional job. 

Daso: What have you learned so far from selling to SMBs?

Yudovskiy, Karpov, and Rozhin: That one should focus on the needs of junior IT professionals, and the rest will come. Outside of prominent corporations, the essential buyers of RPA services are IT professionals, not a COO or CEO. It's important because they have a bit different agendas. CTO of a mid-size bank is interested more in being able to timely respond to all automation requests that come from business rather than in speeding up a loan processing time. It happens to the business margin improvement, but the CTO lense is different. He or she has junior IT professionals as pretty much the only people to deliver RPA internally, so if they can't get up to speed with the tool after the installation, there is shallow interest in moving forward with RPA.    

Daso: Why did you optimize for the IT professional's experience instead of the employee as the end-user? 

Yudovskiy, Karpov, and Rozhin: Because in the heart of RPA is no-API, GUI, automation, and it is a more complicated process than building a Zapier workflow that some IT savvy users are comfortable doing. No-code,end-user approach is pretty much RPA industry marketing bullshit, according to analysts like Gartner, need to engage IT professionals to create bots is the biggest customer disappointment among RPA customers (across all vendors). That's why we decided to be less futuristic (focus on end-users) and more pragmatic (focus on IT professionals). 

Interested in my latest Forbes stories? Subscribe to my mailing list, Founder to Founder: f2f.substack.com.

If you enjoyed this article, feel free to check out my other work on LinkedIn and my personal website, frederickdaso.com. Follow me on Twitter @fredsoda, on Medium @fredsoda, and on Instagram @fred_soda.