Kognitos is attending ITC Vegas, October 14-16 in Las Vegas. See us at booth #454 or join us for dinner at Momofuku.
Kognitos is attending ITC Vegas, October 14-16 in Las Vegas. See us at booth #454 or join us for dinner at Momofuku.
100% to 200% increases in digital marketing ROI
However, sales-ops has one of the most challenging roles for startups as their connective function is filled with many time-sensitive responsibilities and tasks. Even more challenging, the hats sales ops teams wear often change, and urgency is always front and center. Modern sales ops teams not only help provide the systems, tools and processes for account executives to source, close and manage clients, but frequently in startups these same teams are responsible for many critical internal functions including salesperson on-boarding/offboarding, compensation and data for forecasting. Such a demanding function can feel overwhelming for many employees and create friction between go-to-market teams.
In the past, startups would scale their sales-ops function through hiring. But, due to the current macro-economic environment this is likely not feasible as organizations aim to conserve cash. This raises and important question: How can a startup continue to support it’s revenue growth by maintaining a high-functioning sales ops organization while keeping costs low?
The recent crash in valuations of growth stocks and current macro-economic environment ended the “Blitzscaling” or pure growth focus strategy of many startups. Instead, prominent venture capital firms are giving tough advice to their portfolio companies encouraging a focus on limiting expenses and driving towards profitability sooner than previously planned.
“We are just beginning to see how the increasing cost of money flows through to impact the real economy. If you’re stepping back and thinking twice, it’s not just you. Belt tightening and priority reassessment will have second- and third-order effects, as one company’s costs represent someone else’s revenue or purchasing power…” – Sequoia [ii]
Additionally, founders are being warned that the ability to raise capital may be delayed, making cash a priority. But, despite this, growth targets haven’t diminished. This then creates a conundrum for executives and sales-ops leaders: How do we continue to support growth while conserving cash and limiting cost increases?
Traditional approaches for sales-ops won’t work in this environment. Hiring extra staff will increase overhead and be an immediate drain on much needed cash. Implementing new, revenue focused software may help, but also could be prohibitively expensive for earlier stage companies. Even if a startup can afford these technologies they may not deliver the short-term ROI desired to help drive towards profitability as noted by Bain:
“Every major B2B company invests millions each year in sales technologies, yet 62% of 167 companies surveyed recently by Bain & Company said the return on their investment fell short of expectations.”[iii]
What other options does a Sales-Ops team have?
If you consider the type of tasks Sales Ops performs on a day-day basis, automation seems like a natural candidate. Teams move data between systems, handle lots of documentation and orders (either paper or digital), drive insights etc. These are the bread and butter applications for automation. If that’s the case, why then hasn’t automation been used more for sales-ops in startups and why is much of the work still done manually? A few key reasons:
Thankfully, a new way to automate has arrived, eliminating much of the up-front cost and dramatically reducing the services costs of implementing and managing automation. Because of this, automating many sales ops functions is now a prime way for startups to support growth while limiting costs. Kognitos’s NLP based automation places this tool in the hands of sales ops employees. Because Kognitos enables people to automate in plain English, simply typing natural business commands to automate their processes, sales-ops can now quickly remove much of the manual work in their day to day and focus on higher value activities.
At an aggregate level this has many benefits for a startup beyond limiting or reducing cost including:
In the current conditions, one of the best ways that startups can handle a potential slowdown on fundraising and need to drive towards profitability is by maximizing the effectiveness of their teams. This is especially true in the function of Sales-Ops, a highly connective group that helps ensure sales, marketing, finance and support are all able to address customer needs. While traditional methods of increased hiring and the implementation of expensive, revenue specific software may not be feasible, Kognitos new approach to automation, automating in plain English, empowers companies to not only limit costs but drive growth sustainably.
[i] Boston Consulting Group, “Revving Up Go-To-Market Operations in B2B”, 13 May 2020, Revving Up Go-to-Market Operations in B2B | BCG
[ii] Shivani Shinde, Business Standard, “Sequoia asks founder ecosystem to tighten belt, focus on profitability”, 25 May 2022, https://www.business-standard.com/article/companies/sequoia-asks-founder-ecosystem-to-tighten-belt-focus-on-profitability-122052501492_1.html
[iii] Harvard Business Review, “The Sales Playbook of Successful B2B Teams”, 25 August 2021, https://hbr.org/2021/08/the-sales-playbook-of-successful-b2b-teams
The Answer: Empower your skilled workers with automation and the ability to focus on higher level, meaningful work. Kognitos’s automation platform learns business logic from the business user and automates them without the need for a developer or a steep learning curve of a tool. Users can automate even exception laden tasks so they can focus on relational and meaningful work.
Another McKinsey 2021 study shows compensation alone will not retain employees. While having compensation rates commensurate with industry bands is important, many employees highlight other reasons for leaving their current employers including autonomy, and the desire to engage in more relational work. This is especially true of millennials and GenZ, who combined will soon represent over half of the workforce. However, many business processes are not designed to provide skilled employees with this desired work style. Instead, top talent is bogged down in manual processes, and even when attempts at automation occur, is forced to wait weeks or months for results due to backlogged automation teams. Frustrated, they look elsewhere for more meaningful work, costing companies a tremendous amount in recruiting, training and cultural costs. But if automation thrives at reducing manual work (and thus eliminating the problems described above), and if many companies today have some form of process automation, why hasn’t it given employees the autonomy and freedom to engage in the more relational work they so desire?
Traditionally, Automation has been focused on manual, repetitive, rules-based tasks. Naturally, this led to the automation of many back-office tasks previously either outsourced or handled by relatively unskilled labor. But automation has failed at large to take root with more skilled employees, the same employees that managers are struggling so mightily to retain. There are a few reasons for this. The first, is that the day-to-day work handled by a high skill employee often requires lots of exceptions. Processes have variance, and it is for this reason employers pay these employees to problem solve and handle these variations. In fact, this highlights one of the other risks with employees leaving, if an employee who handles a great deal of exceptions leaves, the knowledge of how to best navigate such exceptions departs with them, a significant loss for a company. The number of exceptions present in processes, even processes that are routine and manual, discourages the use of traditional automation, as the cost and maintenance of these processes outstrips their value. Furthermore, employees become frustrated when exceptions need to be built into the automation, as it can often take weeks for a dedicated automation team to build corrections into the workflow. This does not provide the type of autonomy employees desire, but instead leaves them dependent on backlogged development teams and losing faith in automation to benefit their day-to-day work.
In contrast to traditional automation, Kognitos’s platform provides the solution managers need and provides employees with the work experience they desire. Using patented NLP, Kognitos enables employees to problem solve exceptions in conjunction with automation, and through English instruct the automation software as to how to handle exceptions. The platform then learns from this experience and can automate these processes and exceptions in the future. With Kognitos, employees are given the autonomy they desire, no longer have to do much of the work they loathe, and have more time to focus on higher value, more relational work. In turn, greater retention and a happier workforce helps to turn the challenge of the Great Resignation into a truly strategic opportunity for managers.
At Clear Ventures, we looked into the reasons behind the widespread dissatisfaction with today’s RPA industry. After several discussions with large enterprise companies in our own portfolio, it became apparent that RPA’s poor success rate can be boiled down to three primary factors:
• High upfront cost: Contrary to Humans, who learn over time by doing and adapting, RPA ossifies current business processes in software. This mandates a great deal of upfront work to ensure that the business and associated exception cases are clearly captured and programmed. Upfront costs are significantly higher both for bots and, commonly, business consultants who first must optimize the current business process prior to automation.
• High maintenance cost: In theory, a diligent job upfront can reduce ongoing maintenance cost, but the reality turns out to be quite different. Many business processes are simply too complex to effectively document all of the exception cases upfront. And because business requirements change, the processes do as well. This leads to high maintenance costs that often turn out to be the hidden “Achilles’ heel” of RPA.
• Finger-pointing (the blame game): When the automated process fails to work as expected, a blame game often ensues. This RPA project finger-pointing typically is a three-way exercise between the business user, the RPA tool vendor, and the RPA tool programmer. Undermining RPA project failure accountability aggravates the frustration and further increases costs.
RPA at a Crossroads RPA is at a crossroads, and we need a different approach as nobody except perhaps the RPA software vendor is being served well in the current environment. As we looked beneath the proverbial “tip of the iceberg”, we came across deeper reasons for the poor success rate of current RPA implementations including:
It became obvious to us at Clear Ventures that the RPA market is primed for disruption. We evaluated several startups and eventually came across Kognitos which takes a radically different approach from RPA. Kognitos’ solution is centered on two pillars:
• Natural Language programming: Kognitos enables bot and human interaction based upon natural language, eliminating or dramatically reducing the need for experienced programmers. Using natural language slashes both maintenance cost and time to value for the line of business.
• Run-time learning: Current RPA approaches simply crash or freeze when faced with exceptions and edge use cases. When a Kognitos bot encounters unexpected situations, it interacts directly with the business user. Similar to the way in which humans resolve unexpected hurdles, the bot asks questions, learns, and then applies the learnings to modify and continue the process.
We have partnered with Kognitos since the days when the concept was just a glimmer in the eyes of Binny Gill, the gifted product author and architect of the vision. We are thrilled that Binny and his team have come out of stealth and have launched their first product. We look forward to continuing this exciting journey with the Kognitos team as they move into the next phase of the journey to reinvent the RPA industry.
Please visit Kognitos.com for more reading.
Let us dig deeper and find out why.
The promise of RPA has always been that it can do mundane tasks that otherwise would have to be done by a human. In general, that is the primary purpose of computers. The real difference with RPA is in the expectation of who the developer is. In RPA, and also the low code/no code systems, there is the expectation that the business user or the citizen developer will build the automation. There is no requirement of formal computer programming experience from these business users — at least that is the initial marketing pitch, and the demos demonstrate how easy it is for a non-programmer to create an automation via a drag-n-drop UI. And when it works it does seem magical!
But, the dirty secret about any automation is that the initial creation of the software is just the marriage ceremony, married life is what happens next.
The initial creation of automation (or the marriage ceremony), is a beautiful well orchestrated demonstration of good intent and promises. It is the happy path or sunny day scenario. Seasoned software developers know that it is only 20% of the work.
The Day 2 — Day N of automation (or married life), is full of surprises, edge cases, exceptions, changes in requirements, changes in expectations, changes in environment, changes in people, growth and acquisitions. Or as developers call it, “an average day at work”.
The complexity of Day 2 and beyond forced business users to hand over the RPA tools to the IT department which created a Center of Excellence where developers (either in house or consultants) were hired to maintain the automations. That still does not explain the large rate of failure and frustration in RPA projects. We don’t hear of general software projects failing that often. What gives?
Let us double-click into what challenges IT faces when implementing RPA.
RPA systems, more often than not, fill in the functionality gaps between existing business tools. For example, taking an invoice from an email and extracting data from it, performing validations and updating the general ledger; or receiving a record from Salesforce and creating a corresponding record in Netsuite after cross-checks and validations. There are many such processes that humans are manually doing today that RPA helps automate.
However, there is a reason why these gaps exist. Either it is hard to configure the existing products to fill in these gaps, or the existing products don’t have the requisite features. The latter happens when the diversity of integrations required are too large for the software vendors to grapple with, or the environment is quite fluid and unpredictable. For example, a website could change its look and feel breaking automation that depends on it; or a payroll system might change its behavior without coordinating with any financial planning tools that depend on it.
Humans, who fill in those product gaps, are adaptive and don’t crash when a website moves the “Submit” button to a different spot on the page, or when the payroll system rolls out an improved version of their software.
Dealing with a bunch of third party tools and services is hard, and that’s what RPA is tasked to do.
The inherent instability of these environment makes implementation hard, even for the very best developers. The automations created regularly break and are constantly hungry for fixes. This results in “bots” being hungry for “baby sitting”, and the realization that we can only have a few bots. Did we say “married life”?
I have built software products all my life and I know that gathering requirements is not easy. There is a reason why “product manager” is a full-time job. If we don’t invest in figuring out what the requirements are up front, it will lead to later changes which will be more expensive to do. Some of the requirement for a product manager is fulfilled by process mining tools that are deployed in conjunction with the RPA solution. But deploying these tools is also a chore and RPA projects inevitably require many meetings with various stakeholders and business users across the organization with the objective of figuring out the business processes in great detail. Then, based on the stability, complexity and value to business of the process, it is determined whether a process is fit for automation.
If we simply ask the business user to describe a business process in detail, more likely than not, they will miss some key scenarios. Humans have evolved to very quickly figure out the next best step in any situation. But, we have had no evolutionary need to chronicle all the possible paths to take in a complex workflow. Planning is hard, reacting is easy.
Business requirements also change often. In a growing business, processes are created and modified almost every quarter to help the company evolve to the next level of scale and maturity. Acquisitions and mergers can force changes to processes. Governmental regulations may throw a wrench into business process as well. These factors make it uneconomical to produce automation for processes that are subject to change.
Finance, Sales, Marketing, HR and Support are not software development organizations. When business leaders decide to bring in automation tools, they have to decide between hiring developers in-house or leveraging consultants. Today, it is hard to hire talent in the automation space as there are not enough developers trained in these specialized tools. Further, the business users are trying to reduce their workload by offloading it to a machine, and it seems antithetical to the idea to hire a team of humans that now you have to manage. Most enterprises chose to have a combination of consultants and in-house developers to build out the Center of Excellence.
Creating highly maintainable software is very hard when most of team are part-time consultants. Long term owners of software are critical for the success of any software product. If there is churn in the staff maintaining automation, it reflects in poor maintenance of the automation leading to poorer long term results.
RPA succeeds in automating repeated tasks that are narrow in scope and don’t change much. As long as that process is not in an unstable environment and the requirements are not going to change, it is likely to succeed in saving a lot of time for humans. However, those kind of processes are a small fraction of what could and should be automated. Gartner estimates that hyper-automation market to reach $600B by 2022, and RPA will barely scratch the surface of that.
We need to think beyond RPA.
No. It isn’t RPA.
Notice that the fundamental reason for all of the problems around automation is that automation needs to evolve on Day 2, and that is hard to do with RPA. The humans that are currently driving the business processes manually, are inherently able to handle and adapt to unforeseen conditions and are able to rewrite the process as they go along.
The biggest difference between humans and machines is how they behave when something goes wrong.
Can we build such a system that has human-like error handling?
Yes. With the recent advances in deep learning and compiler design, this has become achievable.
Below are the 5 requirements for automation to become human-like.
The above table shows the fundamental difference between machines and humans. When a piece of automation realizes it does not know how to do an action, it just crashes. A human on the other hand, would simply ask the manager, learn the new fact or skill, and continue. There is a reason why we do not need to do “process discovery” before hiring a new employee. The expectation is that the employee will ask if anything is confusing and learn from the answer. So, the training cost of a human gets spread out over time, unlike software engineering which front-loaded with a lot of the development cost.
The table below shows a qualitative representation of this observation. Each business will have different numbers but the picture helps visualize the problem better.
Humans can be trained incompletely and yet be productive to the business.
Machines have to be trained more thoroughly upfront because of cost of making changes later in the lifecycle is steep.
Good software practice is to articulate all edge cases up front and build that into the software. That leads to a large up front cost.
Humans with time get more useful to the business without explicit effort in retraining them. We call them “experienced employees”.
Machines, on the other hand, get ossified and hard to change, and after some time require a rewrite of logic.
If we can handle errors without crashing and change automation without a development cycle, we can fundamentally change the TCO of automation.
Such a system would exhibit:
In a previous article I had articulated the journey towards building such a system that dramatically increasing success rates and reduces TCO of automation. There are two breakthroughs that such a system will possess:
We, at Kognitos Inc., have built such a system and foresee that many others will come forward with similar solutions. The business process automation industry will finally be able to tackle the TCO and scaling problems around automation, leading to more efficient and dynamic businesses in the future.
“No, no.. step through like the machine would. Don’t look at the steps below yet,” I said, visibly annoyed, as my son hastily clicked “Run” and got taken aback by a scary looking stack trace in red.
I remembered going through the same struggles when I was a kid trying to train my mind to trace the steps in a program like a computer would. I knew it was hard, but the hard work would certainly pay off one day. After explaining why x = x + 1 makes sense, and what was the difference between = and ==, I left my son to figure out the rest.
The next morning I woke up with a strange sense of guilt. It dawned on me that my experience of making my first program in BASIC and my son’s experience were actually different. I had it easier!! I learned programming on a handheld CASIO PDA that could understand BASIC. The language was, .. well, very basic. It had a few simple rules, written in a manual that came with it. There were no libraries to import (There was no internet). There was a single window on the screen. One couldn’t write very complex programs as it had a tiny memory. All these limitations actually made things simple. I couldn’t convince myself that my son’s first rendezvous with programming was any better than mine. It probably was worse.
Did we actually regress in all these years?! Computers have become millions of times faster. We have written billions of lines of code. We have the internet! We have the cloud and we have AI! And yet, learning to program computers is still so hard.
I rushed to my son who I found was intently listening to a YouTube tutorial on Python programming.
“Forget Python!”, I said. “What language would you want to use? Assume the computer can understand anything.”
“Oh, like Alexa?”
THAT.
It was one of those moments when you feel you are zooming in and yet zooming out at the same time. A moment of extreme but unnerving clarity. Not knowing that something is hard is such a powerful thing! My son had so easily envisioned the age-old promise that computers will truly understand us, quite like in the old Star Trek episodes from the 60s. He hasn’t seen them. Heck, even I wasn’t born then. But I guess every generation that has worked with computers has wanted computers to think and be like humans.
But look at what have done over the years!
We have trained more and more humans to think like machines. We call them developers. Developers like me.
“Yes.” I said nervously after a long pause. “Just like Alexa. You shouldn’t think like a machine. The machine must think like you.”
The last 90 years of computer science has been extremely successful. Today computers pervade every aspect of our lives. Every business and almost every thing we do will come to a halt if we stop all computers on the planet. Yet, the skill of teaching the computer something new is restricted to less than 0.5% of the world’s population. It’s like the dark ages when only a few people knew how to write and disseminate their ideas through books. Today a large majority of people can write. That was possible because reading and writing are a direct translation of natural language. That isn’t the case with computer languages, which are deeply rooted in math. All computer languages today are descendants of lambda calculus invented by Alonzo Church in the 1930s.
Teaching a computer something new has always been a mathematical task, one that most humans find difficult.
More than a hundred computer languages have been invented since FORTRAN seventy years ago. Each language promising to be better than the last. If those promises were indeed true, and coupled with the fact that computer hardware has become millions of times faster in same time period, today programming should have been orders of magnitude easier than a few decades ago. But, that sadly isn’t the case. Can you make a tic-tac-toe game in 5 minutes? In 1 hour? In a day? Most people just cannot.
However, can you describe a tic-tac-toe game in 5 mins to another human? Hell YES! Oh, in what language? A natural language.
Natural languages do not have to evolve every 5 years like programming languages. Yet, they are sufficiently powerful for expressing the requirements for any computer program before it is written. Can the computer simply understand the requirements as written in natural language?
We are at the dawn of the natural language programming revolution. Today, we are talking to computers via natural language, whether it is on the Google’s search bar, or talking to Alexa or Siri. A deeper multi-step programming paradigm in natural language is inevitable and within reach.
The largest deep learning models like GPT-3 continuing to amaze us with their intuitive prowess. Now, systems like Github copilot are writing code alongside developers in response to natural language comments. However, these systems still do not understand natural language like humans do. They can only develop an intuition for what looks natural based on examples. In order for the computer to learn a novel task based on natural language input, it needs more than experience-based intuition. It needs logic.
The human brain is capable of both intuition and logic.
Intuition is a faculty that helps us decide something without providing the reason. Much like deep learning algorithms today, which identify the breed of a dog in a picture, but cannot provide an explanation for the answer.
Logic, on the other hand, is a faculty that helps us do or decide something while being fully aware of the reasoning or the process. This is what language interpreters and compilers do really well.
Therefore, to build a computer system that can learn like humans via natural language, we need to marry the traditional compilers/interpreters (logic) to today’s deep learning techniques (intuition). Any one of them in isolation is not good enough. The challenge was figuring out how the two can be put together. Where does intuition stop and logic start?
I spent 6 months experimenting with various approaches to building an interpreter for natural language. The ambiguity in natural language used to be an intractable problem just a few years ago. However, recent advances in deep learning, open source models, and python libraries like Flair made it possible to experiment with various approaches for compiling natural language into what a traditional interpreter could understand. I poured through the wonderful book on sentence diagramming, Rex Barks, and while it made me a nuanced student of English grammar, I soon realized that English grammar and Hindi or Sanskrit grammar have some fundamental differences. I strongly believed that both languages get compiled into my brain into the same facts and thoughts.
The structure of information within the brain is bereft of the peculiarities of grammar of any particular language.
It was an a-ha moment.
I threw away everything that was unique to any specific natural language, and what was left wasn’t really a real grammar, but I was convinced that it is much closer to what is represented in our brains. I trained NLP models to understand this pseudo grammar and it suddenly opened up the possibility of high accuracy compilation of natural language statements using deep learning.
The next few months passed in a blur and soon I had the very first example:
I showed it off to my son who was now 13 and had learned a bit of programming himself as evidenced by his informed question.
“That’s cool, Dad! But how does the stack trace look on errors?”
“I am working on it.” I couldn’t control my smile. He had once again hit the nail on the head.
The biggest difference between humans and machines is not how they talk, but how they behave when something goes wrong.
That one problem has defined almost every aspect of computer science. Error codes, exception handling, unit testing, up front requirements gathering, and good software practices all revolving around this fact that we have learned to accept: the machine will crash if we do not tell it in advance how to handle a situation.
A good programmer is someone who writes code that works.
A great programmer is someone who writes code that does not fail.
Foreseeing all the edge cases and exceptions that can happen and writing code up front to handle those is the hallmark of a great programmer. That is a very hard task and a skill understandably rare.
This problem is independent of the programming language chosen. It is a much deeper limitation of computers ever since they’ve been invented!
Contrast this with how humans behave. Ask someone to get a fork from the kitchen. “John, please get me a fork from the kitchen”. John goes to the kitchen, and discovers that there are no forks. John does not crash! And I did not have to say up front:
“John, please get me a fork from the kitchen.
If you don’t find a fork, then get me a spoon.
If you don’t find a spoon, then get me a pair of chopsticks.
If you fall on the way to the kitchen, please get up and proceed.
If you fall on the way back from the kitchen, please get up, grab the fork, or spoon or chopsticks, and proceed.”
A great programmer would have written better code than the above example.
But, in reality, John does not crash! He shouts from the kitchen.
“There are no forks, dude!”
And I say, “Sorry, get me a spoon then”. Then he brings the spoon (and he doesn’t fall on his way back, if you are curious).
Because computers have not been built to make the above dialog possible, good programming has always been meticulous and hard. No choice of language or low code / no-code drag-drop user interfaces can solve this fundamental problem.
We, as a society have come to believe that it is OK for machines to drop the ball when something unexpected happens. We just blame the developer! This has to change.
But, I asked myself. Why did we not create the capability of dialog between computer and user on errors in the last 70 years? The answer surprisingly lies in the choice of the programming language! When the computer hits a problem, it cannot reach out to the user for help, because the user typically did not understand the language in which the computer was programmed. The computer and the user never understand each other’s language and thus could not have a meaningful dialog when the unexpected happened. The computer needed the developer, who was not around when the program crashed.
However, when we start programming computers in a language natural to humans, the computer and the human finally are on the same page. The user can guide the computer and the computer can self-adjust the program to learn how to handle the situation going forward — much like another human would. This is a powerful construct!
At Kognitos Inc, we have just built such a system.
The dialog-based natural language interpreter not only allows the user to program in natural language, but when the system hits an edge case or error condition, the user can provide natural language guidance, which the system learns. Effectively, the program builds itself over time with minor guidance. This dramatically reduces the need for the programmer to think about all the edge cases up front. That truly opens up the door for non-programmers to automate computer systems.
Natural language is fairly vast and ambiguous, but recent developments in computer science are paving the way forward towards computers which can truly understand natural language to learn new skills.
The biggest reason why computer programming has been hard is that it demands the programmer handle myriad edge cases and exceptions up front. With the new dialog-based natural language interpreters, we now see the possibility of computing systems that learn edge case handling during runtime. This truly unlocks the power of programming to all.
We are rooting for a safe future where AI does not run uncontrolled. It needs to be controlled by a layer of logic and process specified by humans. All humans, not just the small fraction who are developers, need to be empowered to control these computers and express their creativity by programming them.
We would love to partner with all those who would like to build a safe future of collaboration between all humans and machines.
Definitely. Us engineers can be huge nerds and we may not always know how to explain things to a customer. But learning from my mentor in the sales field, I learned how to communicate complex ideas and dive down into the customer’s needs. For example, I learned to ask “Three Whys” to get to the real customer pain point. By asking better questions I can help customers solve the real problems and achieve their goals.
Well, in my first automation job I got to work with physical robots in manufacturing, which was really fun as I got to program a robot every day. At the time I had the chance to work on computer vision with physical robots which gave me the chance to, trying to account for every variation, which was a fun big challenge. I’ve always liked the idea of eliminating manual, repetitive tasks and I enjoy getting to decipher the pattern and solve the problem. I’m all about efficiency so that made me stick with the automation industry.
The puzzle solving approach has definitely transitioned into SaaS, but there is a lot more freedom in the process automation space. With a physical robot there is only so much you can do, but in process automation it’s a whole new world. There are all sorts of problems and applications where you can use process automation to solve needs. I like the variety. There are a lot of SaaS point solutions, built for one purpose, but I enjoy being able to use broader tools like Kognitos, as even now there is a lot more we can do with Kognitos than we recognize today.
I always think it’s best to use new tools to complement what you already have. If you have an older tool that is working, and doesn’t have a problem, look to use new tools like Kognitos to complement the existing tools in place. My main goal is for customers to be happy and eliminate manual work. If they need to rip and replace as something isn’t working, fine. But otherwise, use what you have and use newer tech to complement and automate the processes you couldn’t automate cost effectively with older RPA or point solutions.
We have all of these technologies that customers can use, but as technology evolves there will be better solutions and I saw that with Kognitos. With RPA and other traditional low-code environments, you have to outsource a lot of the implementation and maintenance. I think the purpose of automation is to make life easier and that should happen from implementation all the way through production. I think where traditional RPA and low-code fails is in the implementation stage. Those tools make sense to me as I have an engineering brain, but having to translate that to the way a business user thinks is too hard. Their mind is built in a different way to understand things I wouldn’t even begin to understand, so we need to have a tool that caters to that and makes it easy for them to work with automation. With Kognitos, even people who think differently than an engineer can help improve the automation and see it through. That’s why I came to Kognitos, so we can have an automation tool where you don’t have to know everything up front and spend months figuring out all the exceptions. You can start fast and teach the tool as you go (https://www.kognitos.com/solutions)
One thing I really liked was that in each step of the interview process, I felt that my feedback was valued and heard. The team asked me questions about my view on the market, and the product, and actually took those and used them. So it made me feel like Kognitos is a place where I could fit in, belong and we all have the aspiration of bringing automation to the business user.
We are an early stage startup. You have to have the desire to go out there and do things yourself. Don’t just wait and sit on your hands. If you want more responsibility, ask for it. You need to be an independent worker but comfortable sharing your ideas. Get after it and get stuff done as you are with your team trying to build a new future. You’ll only be as successful as your team.
Despite 50 years of widespread computer usage, computer languages lack a toddler’s ability to use a back-and-forth approach to effective communication. And while computers have changed our lives in a great many ways, their requirement to use unambiguous structured language limits their effectiveness at automating business processes. A Formstack study of 280 companies showed that managers spend an average of 8 hours a week on manual tasks.
Computers speak to computers just fine. Highly structured computer languages such as Python, C++, and Java enable seamless handoff of information between machines.
Humans can similarly easily communicate with other humans. This is true even when using computers as intermediaries. Email threads, for example, allow dialogue and negotiation. If you send an email requesting someone to do something that they don’t fully understand or agree with, they’ll email back with questions.
The trouble emerges when humans try to communicate with machines. All computer languages are geared toward unambiguous instructions that the computer interprets in only one rigid way. Close to 9,000 computer languages have been invented thus far and not one comes naturally to humans.
Every company utilizes business processes, and they want to improve efficiency by automating them. Robotic Process Automation (RPA) has emerged as the most common approach, and the market is on fire. According to a ResearchandMarkets report, the RPA market is expected to reach nearly $26B by 2027. A 2016 McKinsey Digital report says that RPA enables a first year ROI ranging between 30 to 200 percent.
But RPA’s dependency upon rigid computer languages limits its effectiveness when business processes are complex or evolving. As an example, even a small insurance business will process tens of thousands of medical insurance claims in a year. When humans do the work, they can easily apply the required business rules while processing the claims.When RPA-enabled computers do the same work, they typically fail when they encounter ambiguities such as missing information or incorrect entries, or novel scenarios that have not been anticipated.
RPA customers attempt to prevent these incidents by first bringing in consultants to discover and optimize their business processes before automating them. A January 2022 ITWeb article, Finding the sweet spot of human-centric RPA, says: “While RPA software can radically improve business processes, building an RPA capability requires significant investment of time, money and people.” Naturally, as the investment increases, the ROI declines.
This lack of easy machine to user communication creates additional costs over time as business processes change – which most inevitably do. Computers are unable to ask the questions required for them to learn how to keep up with changing requirements. Companies must bring in developers to adjust the automation to the new business process requirements. It’s no wonder that an EY survey found that 30% to 50% of RPA projects fail.
Electronic forms such as those used by tax agencies, or the Department of Motor Vehicles are meticulously programmed to allow only certain responses. When filling out a form, if I have a legitimate response unanticipated by the developers, I’m typically not able to submit my input.
As another example, consider the Multiple Listing Service (MLS) for realtors. A realtor needs to manually input data such as the property age, the lot size, etc. over time. If the MLS communicated like people, it could collect information directly from the seller, leaving the realtor more time to sell.
As a toddler begins to learn a few words, effective communication leaps exponentially even if the words aren’t completely correct. The ability for the communication process to handle ambiguity in turn enables the toddler to learn much more quickly.
The same holds true when we use natural language to allow machines to be more like humans. Many developers frown on natural language because it’s ambiguous. But it’s the ambiguity that makes NLP both more accessible and easier to use. The fact that the machine will disambiguate the instructions at run time results in a more robust automation which does not break on changes in the environment.
Natural automation through natural language processing is the antidote to RPA limitations. The system discovers any missing or incomprehensible information and reaches out to the appropriate person for answers, just as a human does, in response to natural instructions. Once the information is received, the system puts it in the right spot in the system of record and goes on to the next step in the business process.
Natural language acts as the common language between the human and the machine allowing both sides to negotiate the path forward when the machine is stuck, and also enabling the human to teach the machine without first getting trained in a computer language. Kognitos uses natural language instruction and exception handling to vastly simplify and reduce the cost of business process automation.
My daughter grew up to be a nuclear scientist, and she utilizes Python in her work. Despite her many years of developer training and experience, I look forward to entering a new era where she’ll again be able to speak with computers as naturally as she did as a toddler when requesting I get her a cookie.
When I was at UiPath, I worked very closely with robotic process automation (RPA) customers, and I witnessed the boundless possibilities of automation on a daily basis. However, I also saw the challenges users faced operationally. While RPA has certainly become more accessible over the years, there are still opportunities for improvement on the customer side when implementing these processes. Just like human employees, robots need to be onboarded. Someone needs to show them what to do and how to do it before they can be productive. Unfortunately, humans are much better at communicating with other humans, but not so great at communicating with machines. In essence, the RPA tools aimed at business users fell into one of two categories: pre-built applications that were easy to customize but lacked functionality, or complex programs that required at least some coding knowledge.
That’s why I was so excited when I heard about Kognitos and its mission to make automation accessible to any user simply by using conversational English. Kognitos founder and CEO Binny Gill had solved one of the biggest challenges to implementing automation by bridging the gap between machines and non-coding humans. This revolutionary leap forward allows any business user to truly realize automations without the need for developers or any kind of programming background.
Barrier-busting innovators like Binny and the entire Kognitos team, and Natural Language Process Automation make me eager to see how more and more people can start automating their tasks and get back to work that actually matters. It’s radical decisions like these that will make the daily grind easier for countless business users and ignite people’s passion for technology, helping to pave a bright road to the future.
