Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: ElectroNeek (YC W20) – Automatically find and automate routine work
132 points by Digitaltzar on July 8, 2020 | hide | past | favorite | 46 comments
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.

This sounds really cool!

However, I wonder about the reliability aspects of it? Many sites are pretty hostile to Selenium and robot-like behaviors. Also, software can change it's layout, colors, icons, etc.

I've seen this with a team that was using SikuliX[0] to automate testing of a GUI application. It worked, but any time the UI changed even a little, the whole automation program would have to be re-done.

In short, I wonder how ElectroNeek solves these issues:

1. Working around software that has been designed to be hostile to automation.

2. Coping with changes to a UI when a software is updated.

3. All the difficult little error handling bits. How do you know if the workflow succeeded? How do you make sure it only happens once? How do you notify the user?

4. Where does the program run? Do you have to have a pile of PCs sitting around running mouse movement scripts in real-time?

Another thing I wonder -- how do the users feel about this? I think many people would be uncomfortable knowing that there is a Sword of Damocles hanging over their head, waiting to automate their job away if it seems too repetitive. I guess that would ultimately be a cultural issue for the company using this tool to solve, but still something I think would be important in order for clients to be successful using it long-term. For example, you don't want to create an incentive for people to try and make their tasks seem non-repetitive in order to avoid having their job automated.

0 - http://www.sikulix.com/

Thank you Charles,

1. Interface elements on windows apps and websites typical have identifiers that allow to hook to them correctly even if visual representation/layout changes so we were ablate automate pretty much any software/website we have tried. Some websites use active A/B testing all the time and theta becomes a challenger, though, doable.

2. This is a fundamental challenge of GUI-level automation, were is no silver bullet to completely eliminate the need for bot 'maintenance'. We allow users to create a library of UI elements that they are using in their workflows, again, their identifiers often allow automatically handle UI changes but if not, users can just relink their interface library with changed GUI elements, without disrupting the bot logic, so it becomes a minor effort to see the bot working in changing GUI environment.

3. (1) Real-time tracking of what the bot does, (2) Logs, (3) 'Exception' port to build custom logic for user involvement/notification at every step of the automated process. For instance, the bot can send you Slack message or email if it ran into an issue.

4. It can run on end-user computers, will look like a cross-application macro, or on a virtual machine/server 24/7 ('unattended' process automation). We partner with Microsoft to bundle our software with Azure infrastructure and make it scalable - so you can deploy more specific bots when the workload for them goes up.

5. You are right, this is a cultural aspect and people challenge. In my own experience, the best way to address is to let people who got a few hours back due to routine elimination to share their experience and how their career path has changed since that, for instance they picked up some analytical tasks that otherwise would require a new hire.

I use this in the wild and like anything it has its pros and cons.

The best usage is automating repetitive tasks in a call center environment. Like you click a "Start my day" button and it opens up and logs you into every application that you use. Then a customer calls in and you put their information in one place and that opens the customer's record in all of those applications. Time is money in call centers and you can save a lot of time with simple stuff like this.

More questionable usage is as a psuedo-api background process. The users fill out a form and that information is sent over to a queue. The robot pulls it out of the queue and then enters it into the slow/confusing legacy backend system. This is good because it's cheaper/faster than building out an API to a legacy backend that is difficult and expensive to change.

The problem is that now you have a brittle and asynchronous communication layer over a legacy backend that is difficult and expensive to change. You compound the problem you have in exchange for quick benefits.

Yes, call center is a great example, as any customer order/processing center that uses many non-integrated IT solutions or where APIs don't provide enough flexibility/customization required workflows to run

I worked on 2 a little bit. Serializing the dom then putting it into probabilistic data structures is the way to go. Bloom filters, lsh hashing, min-sketch are good ways to fuzzy match. UI’s change but for the most part code doesn't.

A lot of commenters are focusing on the RPA part, but what seems to be more novel (to me at least) is the passive discovery of what could be automated with RPA. That seems like a generically hard problem, good luck!

The domain is called "Process Mining.

For example, Rapid Miner: https://www.rapidminer.com

There's also a Coursera:

https://www.coursera.org/learn/process-mining ‎ ‎

There is a good research paper that compares Process Mining to what we do, Desktop Activity Mining: https://pdfs.semanticscholar.org/05a4/f2258a48aaaa2b2686f72f...

Here is the most popular open-source process mining platform:


And thank you for sharing!

Thank you, a great point! We have witnessed so many automation/RPA initiatives put on hold/buried because of the complexity or cost of process discovery, that's why a lot of R&D efforts are focused on this specific stage of automation lifecycle

It’s called process mining and it’s one of those stealthy use cases that nobody knows about but is a multi-billion dollar market.

What we do is a bit different from Process Mining, our approach is known as Desktop Activity Mining, but from a helicopter view it's pretty much the same

Thank you!

Thanks for sharing. I've skimmed your post and headed right to your website in hope to get a quick overview of what you guys are actually doing.

Looking at your marketing communication and seeing Robotic Process Automation I thought, hey cool those guys can build me an assembly-line powered by robots for my new hardware product I'm designing. Then coming back reading a bit more your post (but still too lazy to read it concentrated because it's way too long, I head to the comments and see stuff more in the software automation territory like Autohotkey, Selenium...

I guess I got it all wrong but your positioning is super broad or is it just misleading communication. Whatever, good luck!

RPA is well known in enterprise. But your comment shows that what works for enterprise doesn’t always work for the rest of the market. That goes not just for messaging and positioning but sales and marketing too.

Thanks for the feedback! Robotic Process Automation or RPA is a common name for GUI-level automation but it can be confusing, that's why we more and more often try to refer to what we do as 'software robots' or 'software bots'

It is a known industry term, but it still annoys me. If you can't tap it with a spanner it shouldn't be a robot. (Not moaning at the OP, though)

Useful feedback. Thank you!

Looks fantastic!

I can't find any demo videos on your website that would make it clearer how it actually works, though.

Hey, we host demo videos on our youtube channel https://www.youtube.com/channel/UC014owEr9E1tRVJJKJ3wXdA

Also, check out this recent case of using ElectroNeek to automate accounting data transfer into SaaS tool https://www.youtube.com/watch?v=z5YXsWSGaRM

By the way, you can create a free trial account always and test our solution on your computer!

Super cool to see how much talking to customers has informed your product decisions. Identifying tasks to automate sounds like a hard problem, but I'd imagine it's a huge advantage when making sales. Good luck!

Thank you, James! Yes, finding processes out of the box helps a lot to open the doors that otherwise stay closed

Interesting that you use a lot of the same terminology as UiPath. Orchestrator, Robot, Studio. Even the same OCR libraries.

What's that about? Just the right words for the right concepts?

Yes, these terms actually root in pre-UiPath era and now become the industry standard. OCR libraries are not specific to RPA (e.g. Microsoft OCR,Google OCR, Tesseract, Abbyy) but, again, are pretty much the standard, what we do differently from other RPA vendors is providing users with the ability to visually map scanned template data to variables so it can be done with no code, using only mouse (in line with our focus on simplicity for the developer, works really well for cases when you deal with limited set of templates.

Thanks for the clarification!

You are welcome!

Here is a commercial competitor based on the Kapow web crawler and robot technologies:


Reminds me of AutoHotKey which I used to automate some work for a warehouse a while ago

Yep, it's a right way to think about this as of AutoHotKey on a lot of steroids:)

So LinkedIn has a lot of anti-scraping points in their terms of use. How are you dealing with that?

Where is the tracking data going? Your cloud or theirs? Where are you training the AI's?

If I were to guess, a good chunk of office tasks that need to be automated are Excel related.

Yes, Excel is the ultimate data mashing/analysis tool for most of the office workers, especially in mid-market. Unfortunately, most users import data to Excel manually, collecting them across different systems and reports, and then manually uoload output of their data manipulation to web forms and legacy software, it seems unreal but people some time take a role of an interface between Excel and other systems. That's why we created visual tool for users to automate working with tables (from spreadsheets to databases) without coding, for some reason no other desktop automation software went that far with Excel/G-sheets.

Makes total sense - good luck guys


How do you identify and deal with edge cases and rare situations?

Hi, many repetitive processes have certain exceptions and rare situations when a rule-based logic breaks, typically due to variability of incoming data (e.g. robot finds a text instead of a number in certain template field). Our approach is to (1) provide users with custom exception/error handling logic, e.g. evert robot logic step has an "exception" branch that activates of the bot can't correctly complete the activity; (2) be able to activate "human in the loop' function to bring in user when needed; (3) be bale to work with unstructured data like random invoices to minimize the need for (1) and (2)

I applied to YC with this idea more than 9 times. I guess I'm just a loser

Good luck with your business. it's really awesome you were able to get through to them that this is a huge business

I don't know you, but please don't consider yourself a loser. Ever.

There might be many reasons why you were never accepted to YC, despite applying nine times. Heck, I actually plaude your "stubbornness" / "determination", which is not common.

Don't despair. Sometimes life is hard, sometimes life has other plans for us. Perhaps there's a big success for you just around the corner.

And if not... There's nothing wrong with not being YC-backable. You are still a human being.

Great words!

Hey, please don't be discouraged, for us it worked because (imho) we came to YC interview with existing paid user base growth, so it was far beyond the idea stage. And I personally applied to YC 3 times, starting from 2015:)

This is interesting, leaving comment to remember the post.

Please don't comment for that reason. You can either upvote it or favorite it - both of which lists are accessible later from your profile.


Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact