Choose the process before the tool

The decision this area turns on is which processes are worth automating first, and with what. The order matters: the right tool for a process that should not be automated is still a poor purchase. So the first job is a shortlist of work worth taking off people's hands, and only then a comparison of the tools that could do it.

That holds across everything in this area: workflow automation that moves information between tools, AI assistants and agents, extracting data from documents, and scheduling and intake. Each hands a task to software, and each is judged by the same four questions CROLISVA weighs here: how much time it really returns, how much it breaks when your process changes, where your data goes, and whether you can keep it running without a developer.

Find the candidates: a week of repeated work

Before looking at any product, keep a plain list for one ordinary week of every task someone did more than once. Note what set it off, how long it took and which tools it touched. Candidates tend to look like this:

• Copying the same information from one tool into another, such as a form submission into a spreadsheet or an order into an invoice.
• Work set off by a predictable event: a new enquiry, a booking, a payment, a signed document.
• Reminders and follow-ups that happen only if someone remembers them.
• Reading documents to pull out the same few fields every time, such as dates, amounts or names.
• Answering the same questions in roughly the same words.
• Reports assembled by hand from figures that already exist somewhere else.

Six questions to score each candidate

• How often, and for how long. Multiply the number of times a week the task happens by the minutes it takes. A two-minute task done forty times a week takes more time than an hour-long job done once a month. Use the times you recorded, not estimates made afterwards.
• What a mistake costs. Count the rework when the task goes wrong by hand: a mistyped email address, a missed follow-up, a wrong amount. Automation removes typing slips but repeats a wrong rule every time it runs, so a task where errors are expensive needs a check, not only speed.
• Whether the process is settled. If the steps have changed recently, or each person does the task differently, agree the process first. Automating it now means rebuilding the automation every time the process moves.
• What data and access it needs. List the accounts it would read from and write to, and whether it handles personal or financial data. Every connection is a permission somebody has to grant, and later be able to withdraw.
• Whether the tools can be connected. Check that each tool involved offers a supported way in, such as a built-in integration, a documented connection or an export, and which of its plans includes it. A step with no supported connection is a step a person still does.
• What happens to the exceptions. Note the cases that do not fit the usual pattern: the missing field, the unusual request, the reply in another language. Decide in advance whether each one stops, waits for a person or follows a default.

A rough way to rank the shortlist

CROLISVA's working rule is to compare the time a task gives back over a year with the time it costs to build and keep running over the same year: hours saved per week, multiplied by the weeks it will run, set against the setup hours plus a realistic allowance for fixing and adjusting it. Any subscription or usage charge comes on top.

An illustration, with invented figures that only show the arithmetic: a task that takes 15 minutes and happens 20 times a week uses 5 hours a week. If building the automation takes 10 hours and keeping it working takes 2 hours a month, its first year costs 34 hours against roughly 250 hours of doing the task by hand, before any subscription. A 10-minute task done twice a month would not win back even its 10 hours of setup within the year. Your own figures decide; these do not.

Rank the shortlist by that difference, then move a candidate down if it scored badly on stability, on the cost of mistakes or on exceptions. Start with the one that gives back the most time and has the least that can go wrong.

What an automation really costs

The subscription is only part of the bill. These are the components CROLISVA looks for; whether and how each applies to a given tool is for that tool's own pricing page and documentation to state.

• How the price is measured. Check whether a plan is priced by user, by number of runs or steps, by the volume of data processed or by use of an AI model, and what happens in a busy month that goes over the limit.
• The plan that includes the connections you need, which may not be the one advertised.
• Setup time: mapping the process, building the steps, and testing them on real cases.
• Upkeep: a connected tool renames a field or a login expires, and somebody has to notice and repair it.
• Review time, wherever a person checks results before they are used.
• The cost of a silent failure: work that did not happen, with nobody aware of it.
• The cost of leaving. Check whether automations can be exported; if they cannot, switching tools means rebuilding them.

Data, access and privacy

• Connect each tool with the narrowest access that works: an account or permission limited to the data the automation needs, not an administrator login.
• Know whose name it acts in. Messages sent and records changed by an automation appear to come from the connected account, so choose that account deliberately.
• Find out where data passes through and where it is kept, including run histories and logs that may hold copies of what was processed.
• For an AI tool, read the provider's terms on whether what you send may be stored or used to improve its models, and whether that can be switched off.
• Keep a list of every connection and who set it up, so access can be removed when someone leaves or a tool is retired.
• Where personal data about customers or staff is involved, check the data-protection rules that apply to you. None of this is legal advice.

Where a person stays involved

Automation does not have to be all or nothing. For anything that reaches a customer, moves money or changes records, a safer design is often a draft that a person approves, at least until the automation has a track record.

• Put a human check before anything sent outside the business, any payment and any deletion.
• Treat AI-generated text and extracted data as a draft: a model can return a fluent answer that is wrong, and extraction can misread a field.
• Send exceptions to a named person, with enough context to act on them, rather than letting them fail quietly.
• Make failures announce themselves, through an alert or a daily summary, so that a stopped automation is noticed within a day rather than a month.
• Keep the manual way written down and workable, so the work can carry on if the automation is switched off.
• Prefer actions that can be undone. Before automating one, know how you would reverse it if it ran on the wrong records.

Test one small automation before expanding it

• Take the top candidate on your shortlist and automate one narrow version of it, not the whole process.
• Write down how long the task takes by hand now, so there is something to compare against.
• Run the automation alongside the manual process for a week or two and compare the results case by case.
• Feed it the awkward cases on purpose: a missing field, a duplicate, an unusual request.
• Change one step of the process during the test and note what has to be rebuilt.
• Have the person who will look after it make a change without help. If only the person who built it can maintain it, count that as a risk.
• Expand only when it has run for some weeks without surprises, and measure the time it actually gave back.

When not to automate

• The process is still changing, or nobody describes it the same way twice.
• It happens so rarely that setup and upkeep would outweigh the time saved.
• Each case needs judgement, or a conversation the person on the other side values.
• A mistake would be costly or hard to reverse, and there is no practical point at which a person could check.
• It would need access to data you are not comfortable letting another service hold.
• Nobody would own it once it is built.
• The real problem lies elsewhere, such as unclear responsibilities or a missing step, and automation would only hide it.

Ways to automate, and what each gives up

• Built-in automation or a separate connecting tool. Some business tools include their own rules and reminders. Using those adds no new account and no new place for data to go, but they act only inside that tool. A separate tool that connects several others can automate across them, at the price of another subscription and another set of access to manage.
• Fixed rules or an AI step. A fixed rule does the same thing every time and fails in predictable ways. An AI step can deal with varied text, such as sorting enquiries or drafting replies, but its output varies and needs checking. Use AI where the input genuinely varies, and fixed rules everywhere else.
• No-code or built by a developer. A no-code tool lets the person who knows the process build and change it. Custom code can do more, but depends on someone who can read it. For a small business, the deciding question is who will maintain it a year from now.
• Automating now or tidying the process first. Sometimes the most valuable step is writing the process down and removing a step from it, with no software at all. That also makes any later automation simpler to build and to keep running.