Most automation purchases go wrong in the same way. A team sees a slick demo, watches three colourful blocks connect a form to a spreadsheet, signs a twelve month contract, and then discovers halfway through implementation that the one system holding their customer data has no proper connector. Six weeks later somebody is writing custom API scripts that nobody else on the team can maintain. The tool was never really the problem. The evaluation was.
Choosing automation software is an operations decision before it is a software decision. The platforms on your shortlist are, for the most part, capable of the same broad set of things: watch for an event, move data, apply some logic, write the result somewhere else. What separates them is how they behave at the edges of your specific process, how they price the volume you will actually generate, and whether the people who work in your business can operate them without a specialist on retainer.
This guide walks through the evaluation the way we run it with clients: describe the workflow, map the systems, stress the tool against your worst case, price the full year, and name an owner. Work through it in order and the shortlist usually narrows itself to one obvious answer well before you get to a sales call.
Step one: describe the workflow before you name a tool
Write the process out as a sequence of triggers, decisions and outputs. Not a diagram, not a wish list, just plain sentences: an enquiry arrives through the website form, someone reads it and decides whether it is a real prospect, a record is created in the CRM, a reply goes out within the hour, and if there is no response in three days a follow-up is sent. That is a workflow description. It fits on one page and it is the single most valuable artefact in the whole evaluation.
While you write it, note three things beside each step: who currently does it, which system holds the data, and what happens when it goes wrong. That last column is the one teams skip, and it is the one that exposes whether a platform is genuinely suitable. Every real process has exceptions. The refund that arrives after the invoice was already issued. The enquiry with three attachments and no phone number. The customer who replies to the confirmation email instead of clicking the link. If your written process does not include these, your evaluation will not test for them either.
A useful discipline here is to write the description with somebody who actually performs the work rather than only with the person who manages it. Managers describe the process as it was designed. The people doing it describe the process as it is, including the spreadsheet they keep on the side because the official system does not handle a common case. Automating the designed process while the real process runs on a side spreadsheet is one of the more expensive ways to fail.
Step two: list every system the workflow must reach
Now list the software the workflow touches. Your CRM, shared inbox, accounting package, payment provider, calendar, e-signature tool, support desk, whatever spreadsheets are load-bearing, and any internal database or line-of-business application. Be exhaustive, including the systems that are only involved occasionally, because those are the ones that turn into custom work later.
Against each one, check whether the platform you are evaluating has a native connector, and then check what that connector actually does. This is where most evaluations are too generous. A connector that can read records but not write them is only half a connector. A connector that supports the vendor's newest API version but not the one your account is on is not a connector at all. Open the platform's integration documentation and look for the specific actions you need, not just the logo on the marketing page.
For any system without a usable connector, you have three options, and you should decide which one before you buy rather than after. You can use a generic HTTP or webhook step and accept that somebody will need to understand the target API. You can accept a manual handoff at that point in the process. Or you can replace the system. Each has a real cost. Writing that cost down turns a vague concern into a number you can compare across platforms.
Pay particular attention to authentication. Systems that only support OAuth apps approved by the vendor, or that require an enterprise plan to expose an API at all, can quietly make a cheap-looking platform impossible. It is common for the accounting package or the industry-specific tool to be the blocker, and it is far better to discover that during evaluation than during implementation.
Step three: test on your hardest case, never the demo
Every automation platform looks competent on a linear flow. Form submission creates a row, row triggers an email, email logs to the CRM. That is the demo, and it proves nothing about your business. What you need to know is how the tool behaves when reality intrudes.
Take the messiest genuine example from the last month and rebuild it in the trial. The order with a partial refund and a changed delivery address. The enquiry that arrived twice from the same person under two different email addresses. The invoice that needed manual approval because the amount crossed a threshold. Build that specific case, then break it on purpose: disconnect one of the integrations mid-run and see what the platform does with the half-finished execution.
Three questions answer themselves during this exercise. Can the tool express your actual branching logic without stacking five nested conditions into something unreadable? Does it retry sensibly, and can you replay a failed run after fixing the cause, or does the data simply disappear? And can a competent non-developer on your team follow what the workflow does by reading it? A build that only its author can understand is a liability regardless of how elegant it looks.
If the trial build needs three workarounds to survive your hardest case, the tool does not fit. Workarounds do not get simpler after purchase; they multiply, because each one becomes a precedent for the next.
Step four: price the whole twelve months, not the licence
The subscription is usually the smallest number in the total. Add implementation, whether that is an agency fee or the internal time your team spends building instead of doing their normal work. Add maintenance, because connected systems change their APIs and your own process changes with them. Add the ongoing admin time somebody spends watching run history and fixing failures.
Then model the pricing structure against your real volume rather than today's volume. Per-run pricing looks generous at a hundred executions a month and punitive at twenty thousand, and it becomes genuinely painful when a workflow with retries counts each retry as a billable run. Per-seat pricing looks cheap for two operators and expensive once every department wants edit access. Per-step pricing rewards writing fewer, larger steps, which is often the opposite of maintainable design. Work out what your bill looks like at three times current volume, because if the automation works that is roughly where you are heading.
Set that total against the fully loaded cost of the manual work it replaces. Fully loaded means salary plus employer costs plus the share of software and overhead attributable to that person, and it should also include the revenue consequences of delay: the enquiries lost because the reply took a day, the cash sitting in unsent invoices. When both numbers are written down, the decision usually stops being contentious.
Step five: decide who owns it after launch
Every automation needs a named owner. Not a department, a person. Their job is to watch failure alerts, update the logic when the underlying process changes, and decide when a workflow has outlived its usefulness. Automations without owners do not fail loudly; they drift quietly out of alignment with the business until somebody notices that the reports have been wrong for a quarter.
This constraint should shape the platform choice directly. If your owner is an operations manager who is comfortable with formulas but not with code, a tool that requires JavaScript expressions for anything non-trivial is the wrong tool no matter how powerful it is. If your owner is technical and you expect complex logic, a simplified linear tool will frustrate them within a month. Match the platform to the person who will live with it.
The six criteria worth scoring
Once the shortlist is down to two or three platforms, score each one from one to five against your own workflow rather than the vendor's feature list.
Integration coverage. Native, bidirectional connectors for every system in the process, plus a usable HTTP or webhook step for the ones without. Count actions, not logos.
Logic depth. Branching, loops, scheduled waits, retries and error handling. Linear if-this-then-that tools stall on real business processes somewhere around the second exception.
Pricing model. Model your actual volume, including retries and test runs, at today's level and at three times today's level.
Data control. Where data is stored and processed, how long it is retained, whether payloads are visible in logs, and whether self-hosting is available if a client or regulator ever requires it.
Observability. Run history you can search, failure alerts that reach a human, and audit logs showing who changed what. Without these you find out an automation broke when a customer complains.
Exit path. Whether you can export workflow definitions and historical data in a usable format. Migration cost is the real switching cost, and it is cheapest to check before you are locked in.
Red flags that predict a bad fit
Some signals reliably indicate a platform will not survive contact with a real process. Pricing that only appears after a sales call and a signed NDA usually means pricing that scales with your desperation rather than your usage. No sandbox or trial that lets you build your own workflow means you are being asked to buy on the strength of a curated demo. Connectors that read but cannot write are half-built. Error handling that consists of an email saying something failed, with no replay and no context, will cost you hours every month. And a roadmap answer for every feature you need today is a polite way of saying no.
One more, less obvious: a platform whose community and documentation are thin. When something breaks at four in the afternoon on a Friday, the difference between a searchable forum full of similar cases and a support ticket queue is the difference between twenty minutes and three days.
Five questions worth asking before you sign
Ask what happens to an in-flight run when a connected system times out, and whether the run can be resumed rather than restarted. Ask how you are billed when a workflow retries after a failure. Ask whether you can restrict who is able to edit production workflows, and whether there is any staging concept at all. Ask what the export format is for workflows and logs, and request a sample. And ask, naming your systems specifically, which of them have native bidirectional connectors and which will require custom work.
Vendors answer these questions honestly more often than people expect, largely because so few buyers ask them. The answers also tell you something about the relationship you are entering: a vendor who describes a limitation clearly is usually a better long-term partner than one who deflects to the roadmap.
All-in-one suite or best-of-breed with an orchestration layer
The other structural decision is whether to consolidate. All-in-one suites promise a single vendor, a single bill and a single support contact, and for governance that is genuinely attractive. In practice they rarely fit every process, and the modules that are weakest tend to be the ones you use most. Most small and mid-sized teams do better keeping the CRM, accounting package and support desk they already know, then adding an orchestration layer between them.
Consolidation makes sense in one clear scenario: when you are replacing several systems at once anyway, usually because the existing ones are genuinely unfit or because a merger has left you with duplicates. Migrating to a suite as part of a deliberate rebuild is reasonable. Migrating to a suite in order to simplify your automation strategy is usually the expensive route to a worse fit.
Frequently asked questions
Where to start
If you do nothing else from this guide, do the first step. Write one page describing one workflow, including who touches it, which systems hold the data, and what happens when it goes wrong. That page will tell you more about which platform you need than any comparison table, including ours, and it costs an afternoon rather than a contract.