Workflow automation: take one process your team does by hand and make it run itself

Who this is for

Somewhere in your business there is a process that works only because one person remembers to do it. Every Monday someone exports three reports and pastes them into a slide. Every invoice is checked against a purchase order by eye. Every new lead from the website is read, categorised and forwarded by hand. Every supplier who has not confirmed a delivery date gets a chasing email, if anyone has time.

These processes are not hard. They are frequent, dull, and expensive in a way that never shows up on an invoice. Workflow automation takes one of them and makes it run without the person, with a log that shows it ran.

One process, end to end

We do not sell "automation" in the abstract. Each job is one named process, from the event that starts it to the result that ends it, with every step written down before we build. The scope says what triggers it, what it reads, what it decides, what it writes, who gets told when, and what happens when something does not fit.

End to end matters. An automation that does four of five steps and leaves the fifth to a person is still a process that depends on someone remembering. If a step cannot be automated safely, the scope says so and the automation hands that one step to a named person with everything they need already prepared.

Examples of processes we build

• Supplier follow-up: every open purchase order past its expected confirmation date gets a chasing email in your wording. Replies are read, the confirmed date is written into your system, and the ones that need a decision (partial shipment, price change) land on the buyer's desk with the thread attached.
• Invoice matching: incoming supplier invoices (PDF, email body, portal download) are read, matched to purchase orders and goods receipts, and either marked ready to pay or placed in an exceptions list with the mismatch highlighted: quantity, price, missing receipt.
• Lead routing: every enquiry from your site, marketplace or inbox is read, classified by product line, size and urgency, enriched with the company's public details, entered into your CRM and assigned to the right person, with the junk filtered out before anyone sees it.
• Catalog enrichment: new products arrive as a supplier spreadsheet with a part number and a terse description. The automation writes the draft title, description, bullet points and attributes in your house style, flags the ones where the source data is too thin, and loads the drafts into Shopify, WooCommerce, Magento 2 or BigCommerce for a person to approve.
• Weekly reporting: sales, stock, ad spend and support numbers pulled from their sources on a schedule, reconciled, and delivered as a short written summary with the tables attached, in your inbox before Monday's meeting.

Each of these touches two to four systems and has clear rules with a manageable number of exceptions. That is the profile of a process worth automating.

Choosing the tool honestly

The industry around automation sells tools. We do not have a tool to sell, so the choice comes from the process:

• Plain code (Node or Python, running on a small service or a scheduled function on your cloud account) when the rules are fixed, the volume is high, or the data is sensitive. It is the cheapest to run, the easiest to test properly, and the least likely to break when a vendor changes its pricing.
• An AI model for the steps that read or write variable text: understanding a supplier's email, classifying a lead, drafting a description. We use a model only for those steps, with a confidence threshold, and never for arithmetic, matching or anything a lookup table does better.
• n8n or Make when you want to see the flow, change a step yourself, and the volume is modest. n8n can run on your own server with no licence cost; Make is simpler to start and charges per operation. Both are good for processes with many small integrations and few hard rules.

Often the answer is a mix: n8n for the connections and the visible flow, a custom node of plain code for the fiddly step, a model call for the one step that reads text. The fit check tells you which, and why, before you pay anything.

Error handling and logs

Most automations fail quietly, which is worse than not having one. Ours are built so that failing is loud and visible:

• Every step validates what it receives before acting. A record that does not fit goes to an exceptions list, with the original attached, rather than being guessed at.
• Every run writes a plain-language log: what it read, what it decided, what it wrote, and what it skipped. You can read it without an engineer.
• Anything that fails twice sends a message to a named person. Nothing is retried forever.
• Steps that write to your systems can be run in a dry-run mode that shows what would have been written, which is how we test before launch and how you test after a change.
• A weekly summary tells you how many records ran, how many were exceptions, and how long each step took.

When not to automate

We turn down work that will not pay back, and the fit check says so plainly:

• Jobs under $2,500. Below that, scoping, testing and supporting the work costs more than the work. A two-step connection you can set up in Zapier or your platform's own rules should be set up there, and we will name the tool.
• Fragile inputs. A process fed by documents that change layout every month, or by a person's free-form notes, will generate more exceptions than it saves. Fix the input first; sometimes a form or a template is the whole answer.
• Rare processes. Something done once a quarter by one person for an hour is cheaper done by that person.
• Processes nobody can describe. If three people do it three different ways, there is a decision to make before there is anything to automate. We will say so rather than encode the confusion.
• Processes that are really decisions. If every record needs judgement, a model will not remove the person; it will just make the person check its work.

A worked example

The numbers below are illustrative. They show the shape of a typical job, not a result we are claiming for a client.

What it costs

Half the fee at start, half at launch, by wire transfer or PayPal. Running costs (model fees, hosting, any n8n or Make plan) are billed by the providers to your own accounts and estimated in the fit check. We do not take jobs under $2,500.

How it runs

1. Free AI fit check (2 working days)

   You describe the process in a sentence and name the systems. We check what their APIs allow, sketch the steps and the exception paths, and send a one-page plan with the tool choice, a running cost and a fixed price. If the honest answer is "use this tool yourself" or "not yet", the plan says so.

2. Scope (1 week)

   Written scope: trigger, steps, rules, exception paths, who gets told, and the test cases drawn from your real records. Accounts created in your name. Half the fee paid.

3. Build and dry run (1 to 3 weeks)

   Built on your accounts against copies of your data, run in dry-run mode over a month of real records so you can see every decision it would have made. Daily written log.

4. Launch (1 day)

   Switched from dry run to live. Second half of the fee. You receive the code or workspace, the documentation and every credential.

5. Tuning (30 days)

   We read the exceptions list and logs with you weekly, tighten rules, and handle the first format changes. Then the care plan, or nothing further.

Start with the fit check

Get a free AI fit check: one sentence about the process, one page back in two working days with a tool choice and a fixed price. Or email info@riantsoft.com and describe the thing someone on your team does every Monday.

Questions people ask