Every automation project starts the same way. Somebody in operations maintains a spreadsheet called final_v3_USE_THIS.xlsx, and it is load-bearing. (Mine is called expenses.xlsx. I automate other people's busywork for a living and still key in my own receipts by hand. Physician, heal thyself.)
So you start shopping. And you find that "business process automation companies" is not one category. It is at least six, and they do genuinely different work, with different artifacts left behind when the invoice clears. This page compares them on the criteria that actually decide the outcome: where the business logic ends up living, how the work reaches you, and the way each category tends to fail.
No vendor logos, no scorecard theater. Just the shapes.
Start here: the answer in four sentences
Pick the vendor type that matches where your process breaks, not the one with the best deck.
If the breakage is repetitive keystrokes against a system with no API, you want an RPA partner. If it is approvals and forms across tools that already talk to each other, a low-code consultancy will get there faster and cheaper. If the process is the product, meaning your margin, your clinical safety, or your differentiation lives inside those steps, you want a custom engineering partner who will build it as software and hand you the source. Everything else is a question of scale and governance.
The rest of this page shows the working.
Six types of business process automation companies, side by side
| Vendor type | Best fit | How the work arrives | Where business logic ends up | Typical integration method | Main failure mode |
|---|---|---|---|---|---|
| RPA implementation partners | Legacy systems with no API, high-volume repetitive data entry | Bots per task, often priced per process | Inside the bot script and the vendor's orchestrator | UI automation, screen and field recognition | A vendor UI update breaks the bot, and the fix is not yours to make |
| Low-code and no-code consultancies | Forms, approvals, notifications, light data sync between SaaS tools | Configured apps and flows on a platform you license | Inside the platform, as configuration | Prebuilt connectors and webhooks | Logic grows past what configuration can express, and nobody can read it anymore |
| Global systems integrators | Multi-country rollouts, change management, process governance programs | Large programs with workstreams and steering committees | Spread across documents, platforms, and subcontractors | Enterprise middleware and integration suites | Months of discovery before a single automated run reaches production |
| Staff-augmentation vendors | You already have the architecture and a product owner, and need hands | Developers by the month, directed by your team | Wherever your team puts it | Whatever your team already chose | You own the design mistakes, because you made them |
| Vertical SaaS with workflow modules | Standard processes inside one domain, where your way matches their way | A subscription and a configuration project | Inside the product, bounded by what it supports | Native to the suite, plus an API if you are lucky | The one step that makes you different is the one step the product will not do |
| Custom product engineering partners | Workflows that cross several systems, carry exceptions, or touch regulated data | Discovery, then shipped software in your repositories | In your codebase, as explicit, testable rules | Direct API, event, and queue integration | Costs more up front than a connector, and the first release is not next Tuesday |
Comparison based on the engagement model each category publicly operates under and on where each one stores business logic after delivery. Prices are excluded on purpose, since the six categories quote on incompatible units (per bot, per seat, per workstream, per sprint, per scope).
One clarification, because the market blurs it. "Automation company" and "AI company" have merged in the marketing and stayed separate in the work. Most of the value in a process still comes from removing re-keying, not from a model. If a human copies the same value into two systems, that is the automation. The language model comes later, for the part where someone reads a fax and decides what it means. (Yes, fax. US healthcare runs on it. I have made peace with this in the way you make peace with weather.)
Which one fits your situation
Here is the rule we use before quoting anything, and it needs two numbers from you.
Count the systems the process touches. Count the exceptions per hundred runs, meaning the times a human has to step in and decide something.
Two systems and low exceptions, buy a tool. Three or more systems, or a double-digit exception rate, and configuration will hold for about nine months before it becomes a haunted house. That is the whole heuristic. It fits on a napkin, and it has saved clients more money than any architecture diagram I have drawn.
| Signal in your process | Where it points |
|---|---|
| Target system has no API and the vendor has no roadmap for one | RPA partner, with a plan for the day the UI changes |
| Process is stable, the data is boring, the volume is modest | Low-code consultancy or a workflow module you already pay for |
| Program spans several business units and regulators in multiple countries | Global systems integrator |
| Architecture is set and your product owner is strong | Staff augmentation |
| The differentiating step is the step no product supports | Custom engineering partner |
| Output carries clinical, financial, or legal consequence | Custom engineering partner, with an audit trail per state transition |
Basis: the structural fit between each engagement model and the two variables above, systems touched and exception rate.
The tradeoff is real and worth stating plainly. Configuration is faster and cheaper this quarter. Code is cheaper the third time the process changes, because a change becomes a pull request with tests instead of an archaeology dig through 40 flow screens. Pick based on how often the process actually changes, not on how often you hope it will settle down. In our experience it never settles down. Processes are not furniture.
A second tradeoff, less discussed. RPA gets you running against systems that will never open up, and that is genuinely useful. It also means your automation depends on another company's button positions. That is a fine bet for a back-office reconciliation task. It is a poor bet for anything a patient or a regulator touches.
What to ask on the first call
Use this list on every vendor in your shortlist, including us. The answers sort the field faster than any reference check.
- Where does the business logic live after you leave, and can we read it without your platform
- Who owns the source code and the pipelines on day one
- How does a failed run resume, and does it resume from the step that failed or from the beginning
- What happens to a run that needs a human decision, and is that exception queue a product feature or a support ticket
- Are outbound calls idempotent, so a retry does not create two invoices or two orders
- Is there an audit record per state transition, with actor, timestamp, and the payload that caused it
- Which steps are tested automatically, and what does the suite cover besides the happy path
- How are releases approved, and who can push to production
- If the counterparty system changes a field next quarter, what is the fix and who pays for it
- Does the engagement include a signed BAA when the workflow touches protected health information
Basis: the ten failure points we see most often in automation handovers. Items 5, 6, and 10 are the ones vendors most often cannot answer on the spot.
A note on item 5, because it is the quiet one. Idempotency keys are a line of code and a database column. Skipping them is how a retry storm turns into duplicate charges, duplicate claims, and a very long Friday. It is the "we're gonna need a bigger boat" moment of your automation program, except the boat is your finance team's reconciliation sheet.
Regulated workflows change the math
When a workflow carries protected health information, the comparison above narrows.
The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic PHI, including audit controls and access management, as set out by the US Department of Health and Human Services. That requirement does not stop at the application boundary. It covers the automation layer, the queue, the logs, and anything a bot screenshots on its way past a chart.
Three consequences follow, and they are practical rather than theoretical.
A business associate agreement is not a formality. Every party that touches PHI on your behalf needs one, including the automation platform and the implementation partner. Ask early, because this question has ended more shortlists than any technical review.
Logs become a design decision. Default verbose logging in an integration layer will happily write a patient identifier into a log aggregator with a generous retention policy. That is a breach waiting on a calendar. Field-level redaction belongs in the first sprint, not the hardening sprint.
Interface work favors standards over screen scraping. HL7 FHIR gives you versioned resources, defined identifiers, and a contract that survives a vendor release. A bot clicking through an EHR interface gives you none of those. For anything clinical, we start from the API and treat UI automation as the fallback it is.
If this is your situation, the relevant depth is on our healthcare workflow automation page, which covers intake, eligibility, and documentation workflows specifically.
How we scope automation work
We map the process first, in notation, not prose. Business Process Model and Notation 2.0 is an Object Management Group standard, and it exists so a diagram means the same thing to your operations lead and to the engineer implementing it. Gateways, events, and exception paths get drawn before anyone opens an editor. Most of the arguments happen on the diagram, which is where arguments are cheapest.
Then we find the exception paths and price those honestly. The happy path is usually 20 percent of the work. The other 80 percent is the partially filled form, the duplicate record, the payer who returns a 200 with an error in the body, and the step where a human has to look at something and decide. If a proposal only describes the happy path, it is not a proposal. It is a wish.
Then we build it as software. Workflow state persists as an explicit state machine, so a run that dies on step six resumes on step six. Outbound calls carry idempotency keys. Retries use backoff with jitter. Failed runs land in a dead-letter queue that a human can inspect, correct, and replay, because a run that silently disappears is worse than one that loudly fails. Each state transition writes an audit row with actor, timestamp, and payload.
Releases go through code review and release approval. We hold access, not assets, and the code sits in your repositories from the first commit.
If the question is sequencing rather than building, a technical advisory engagement covers the process map, the build-versus-buy call, and the integration plan, without committing you to a delivery contract. When the scope is clear enough to price, estimate your project and we will come back with a number and the assumptions behind it.
Related work
- AI prototype sprint, for teams that want a working, testable automation in front of real users before committing to a full build.
- HIPAA-compliant software development, for the control design behind workflows that touch PHI.
Automation is not magic and it is not a license. It is a process you understood well enough to write down, plus the discipline to handle the parts that go wrong. Get the exception path right and the happy path takes care of itself. Get it wrong and you have built a very fast way to create the same mess, which, for the record, is still an improvement on final_v3_USE_THIS.xlsx.
