Launch HN: ElectroNeek (YC W20) – Automatically find and automate routine work https://ift.tt/2BIZnbc

Launch HN: ElectroNeek (YC W20) – Automatically find and automate routine work Hey Hacker News! We are Sergey Yudovsky, Dmitry Karpov and Mike Rozhin, founders of ElectroNeek ( https://electroneek.com ), an automation platform for repetitive business tasks. The product we build let users design software ‘robots’ that imitate human actions in apps and websites, and deploy them to eliminate routine work. Our software also spots patterns of repetitive processes that users do in business app and suggests what to automate in the first place. Some of you may have heard of a technology niche called Robotic Process Automation, or RPA. Basically, it’s about automating user actions on Graphic User Interface level, so no API is needed to automate any type of repetitive work on the computer. It has been known for 20+ years in the software testing space but emerged as a business process automation tool over the last decade, getting big momentum in Enterprise (95% of Fortune 500 use it for back-office task automations). If you know what Selenium is and how it automates work in browsers you may think of RPA that is a Selenium on steroids that can work in any desktop or SaaS app. Basic RPA bots interact with app interfaces using mouse and keyboard, so if some repetitive process can be described by an instruction it can be automated (in theory) with RPA. There are a few fundamental issues with GUI-level automation (like, how should a programmed bot behave if the interface has changed?) but the major limit historically has been the complexity of RPA bot development and administration. The biggest benefits of RPA come from automating complex tasks, sometimes even end-to-end jobs across multiple pieces of software and websites. As you might expect, this approach to automation works great until it doesn't, and then someone has to step in with duct tape, a.k.a. write glue code to stick the pieces together, especially when it comes to variables, cycles and unstructured data (a lot of real business documents). RPA turned into something that business users can not use without having coding experience, which defeats the whole purpose. In 2016-2018, Sergey and Dmitry, long time friends, separately got into RPA consulting business on two different continents. Sergey ran his own boutique firm that worked with big banks and natural resource companies in Eastern Europe and Dmitry was in charge of RPA branding and marketing strategy at EY’s Americas business. The idea to build new software in the space came from Sergey’s inbound marketing pipeline – many mid-market companies understood the benefits of RPA, attended Sergey’s firm demos of RPA bots in action, but walked away from implementations because they haven’t been able to afford them due to limited in-house IT resources and absence of a budget for consultants. ‘Too complex and expensive’ - the most common feedback of such potential clients who in fact were underserved by major vendors and integrators. To move forward with making RPA easier for such customers, Sergey and Dmitry brought in Mike, Dmitry’s college friend with a major in mathematics and career in cloud architecture. We got some momentum among small banks, insurance companies and other companies with relatively tiny IT teams. But then we realized that there are obstacles with this market. The biggest problem lies in finding what to automate in the first place. There is lots of manual repetition going on in companies that people just don't notice. Managers and IT often understand the RPA tech and its capabilities, but struggle to find where to start. An even bigger obstacle to automation is the need to learn complex tools and in fact, the need to code in order to automate significant routines. It turns out that navigating desktop or website interface requires more complex logic than taking data from SaaS A to SaaS B (the land of Zapier). Over the time we adopted a mantra ‘if it can be done with a mouse only, without touching the keyboard, it should be automatable in this way'. At present, about 25% of our bot developers are non-IT. Typically their role in a company is related to working with analysis or operations data. They benefit from automating data extraction or data entry tasks and are motivated enough to learn a new tool to make their own life easier. These ‘Citizen Automator’s’ have a very simple decision-making process when they evaluate automation opportunities: will I get back the time I invest in designing a workflow? What are the time gains? If so, I invest my time and request a budget for a solution. Our big insight about how to solve these obstacles came from the simple idea that ‘robots’ that execute automations also have all the capabilities to passively monitor how users interact with different interface elements, mouse, keyboard, etc. Why not let the ‘robot’ look at what you do in the first place, and attempt to find whether you run the same process repetitively, even if runs are spaced in time. Normally this could be seen as an invasion of privacy but, unlike with time trackers, the purpose of this monitoring is not a control of how people spend their working hours but the voluntarily search for automation possibilities for giving time back to people. From that we built a simple repetitive-actions analytics tool that any users, regardless of IT experience, can use out of the box. Users across a company can download a client that passively monitors how they interact with different interface elements (forms, buttons) across whitelisted applications and websites, looks at clipboard frequency, mouse and keyboard usage patterns. On the back end, the cloud portion of the software identifies repetitive patterns and estimates potential (in hours) for automation on the level of software, users, and the organization. For instance, if a user often switches between 2 application windows and uses Ctrl+C/V in each iteration, this is a pattern of repetitive process that can be automated with RPA. The platform counts specific automation opportunities (like copy-pasting, repetitive click-throughs) to give a better sense on what exact routine it identified. These types of job are common for RPA automations. Even more common is the case of clicking through a legacy system to process a transaction (for instance, underwriting insurance) – users click on interface element on the same screens in the same orders for 30+ times and don’t even think of accelerating the clickthrough with automation. Or accounting case – many CPAs charge clients for manually uploading ledger account into cloud accounting software, taking data from excel to web forms. ‘Robots’ will ‘eat’ such tasks. Once the repetitive patterns have been identified, it’s time to start automating. Designated users can build bots with no code/low-code. Finding and eliminating inefficiencies is a pretty addictive process. When you have an automation tool in your hands you definitely look very differently at how your teams spend their working hours. On the business side of the house, we adopted SaaS model and charge clients for the access to process discovery and automation suite that has both web and downloadable parts. We eat our own dog food a lot: all of us, from sales and marketing to product, have our own set of automated workflows. In sales, we use bots to automate going to LinkedIn Sales Navigator to enrich contact lists, to check emails in these lists against spam databases (using tool named Scrapp) and then to build email sequences in Gmail, bypassing # of sent emails limit set by CRM vendor on our plan. We're really happy to get to this point and share our story here, thank you for reading about it! Please let us know your thoughts and questions in the comments. July 8, 2020 at 06:30PM