
Launch HN: ElectroNeek (YC W20) – Automatically find and automate routine work - Digitaltzar
Hey Hacker News! We are Sergey Yudovsky, Dmitry Karpov and Mike Rozhin, founders of ElectroNeek (<a href="https:&#x2F;&#x2F;electroneek.com" rel="nofollow">https:&#x2F;&#x2F;electroneek.com</a>), 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.<p>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.<p>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.<p>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&#x27;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.<p>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.<p>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&#x27;t notice. Managers and IT often understand the RPA tech and its capabilities, but struggle to find where to start.<p>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).<p>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&#x27;. 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.<p>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.<p>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&#x2F;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.<p>Once the repetitive patterns have been identified, it’s time to start automating. Designated users can build bots with no code&#x2F;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.<p>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.<p>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&#x27;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.
======
charlesdaniels
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/](http://www.sikulix.com/)

~~~
treis
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.

~~~
Digitaltzar
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

------
bradyo
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!

~~~
mikhailfranco
The domain is called _" Process Mining._

For example, Rapid Miner:
[https://www.rapidminer.com](https://www.rapidminer.com)

There's also a Coursera:

[https://www.coursera.org/learn/process-
mining](https://www.coursera.org/learn/process-mining) ‎ ‎

~~~
Digitaltzar
There is a good research paper that compares Process Mining to what we do,
Desktop Activity Mining:
[https://pdfs.semanticscholar.org/05a4/f2258a48aaaa2b2686f72f...](https://pdfs.semanticscholar.org/05a4/f2258a48aaaa2b2686f72f94437ae24729ec.pdf)

------
35post
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!

~~~
gk1
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.

------
cpr
Looks fantastic!

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

~~~
Digitaltzar
Hey, we host demo videos on our youtube channel
[https://www.youtube.com/channel/UC014owEr9E1tRVJJKJ3wXdA](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](https://www.youtube.com/watch?v=z5YXsWSGaRM)

------
jamestimmins
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!

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

------
maxehmookau
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?

~~~
Digitaltzar
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.

~~~
maxehmookau
Thanks for the clarification!

~~~
Digitaltzar
You are welcome!

------
mikhailfranco
Here is a commercial competitor based on the _Kapow_ web crawler and robot
technologies:

[https://www.kofax.com/Products/rpa/overview](https://www.kofax.com/Products/rpa/overview)

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

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

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

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

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

~~~
Digitaltzar
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.

~~~
chaostheory
Makes total sense - good luck guys

~~~
Digitaltzar
Thanks!

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

~~~
Digitaltzar
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)

------
mongojunction
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

~~~
simonebrunozzi
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.

~~~
Digitaltzar
Great words!

------
SMAAART
This is interesting, leaving comment to remember the post.

~~~
dang
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.

