RPA, what it means when somebody says it to you

It's an acronym that goes round in presentations, underneath there's something simple

Lines of code on a monitor in the middle of the office paperwork

Underneath the acronym there's a single sentence

RPA stands for Robotic Process Automation, and it means something you can explain in one line, having a program do the clicks and the typing a person does in front of the screen today

There is no robot with arms, and there is no brain doing any reasoning, there is a piece of software that opens the same screens an operator opens and hits the keys in the order you told it

When somebody says RPA to you in a presentation, this is what they're saying, the rest is packaging

The idea is old, what has changed is how well it holds up

Having a program drive the screens is nothing new, it's been done for a long time, and anybody who has worked in an office over the past years has seen some homemade version of the same thing, maybe a macro that did half the job until it broke

What has changed isn't the idea, it's that today a system of that kind copes much better with the awkward cases, the window that takes three seconds longer to open, the field that shifts by two pixels, the document that arrives written another way, and when it really can't make sense of what it sees it stops instead of guessing

Those products are made for large companies

Most of the products sold under the RPA acronym were built for companies with hundreds of people, and it shows, licenses to renew for every workstation that runs, a platform to learn, people inside who manage it, a project that goes on and has to be governed

In that setting it makes perfect sense, because there are dozens of different processes and you need a single place to keep them

In a company of ten people with two or three repetitive jobs to get out of the way, that same structure is a weight you pay for without using, you find yourself maintaining the tool instead of the result

In most small cases a system built around that one process is enough, one that does that thing and does it always the same way

What changes for you

If what interests you is the result and not the word, the right question isn't whether you need RPA, it's whether the work you want to take away has volume, has rules that can be written down, and doesn't call for a judgment on every case

Muffin Suite works on exactly this ground, automations that open the screens of the program you already use, even when it has no direct integration at all, without you having to replace your software and without a new platform to learn

Where a direct integration does exist, that's the one we use, because it's more solid, and before taking it for granted that the screens are the only way, read what an API is and why your business software may not have one

If a supplier talks more about the acronym than about your process, ask them to describe step by step what the system would do on Monday morning

What people usually ask us

RPA stands for Robotic Process Automation, and it means having a program do the clicks and the typing a person does in front of the screen today, opening the same windows and filling in the same fields, with no physical robot and no reasoning behind it
No, RPA is not a new technology, driving the screens with a program has been done for a long time, what has changed is how well it holds up, today a system of that kind copes much better with the awkward cases and stops instead of guessing
Almost never, most of those products were built for large companies with dozens of processes to govern, while in a small company with two or three repetitive jobs a system built around that one process is usually enough, with no platform to administer
Yes, if by RPA you mean the substance, Muffin Suite writes automations that open the screens of the business software or the portal you already use and fill in the fields the way an operator would, without selling you platform licenses and without asking you to replace your software
An automation built properly stops instead of guessing, and that is the point that separates a system that lasts from a fragile one, because the case nobody planned for ends up in a queue for a person instead of becoming wrong data inside your business software
No, where a direct integration exists we use it because it is more solid, but when there is none we go through the screens and the work gets done all the same, and that is exactly the Muffin Suite specialty, closed programs that talk to nobody

Show us what you still do by hand

Describe the process or send a short screen recording and we'll tell you what can be automated

WA