你引以為傲的無程式碼自動化，可能正是你會關掉的那一個

A chain of no-code steps calling an LLM can look like a finished automation. It moves a form submission into a spreadsheet, drafts a reply, tags a document, and everyone in the demo nods. Six weeks later the same team is doing the task by hand again, and if you ask why, nobody can quite say when it stopped. That gap between a demo that works and a system people trust is where most automation budgets quietly disappear.

The usual advice is to start small and prove value with a quick win. I think that advice is backwards for anything customer-facing. A small automation that fails silently doesn't prove value. It teaches your team that automation is unreliable, and that lesson is expensive to unlearn.

The failure is rarely the model

Ask people why an automation got abandoned and they'll often blame accuracy. The model got things wrong, so we turned it off. Dig a little and the real story is usually duller. An API key expired. A webhook fired twice. A file arrived in a format the parser didn't expect. A step timed out at 2am and the queue behind it stopped moving. Nobody noticed until a customer did.

That is not an accuracy problem. It is an observability problem, and it is the one thing no-code tools are worst at. When the board is someone else's product, you inherit their idea of what "failed" means, and their idea rarely includes a dead-letter queue, a retry policy, or an alert to a human who can act on it. You can't debug what you can't see, and you can't see inside a tool you're renting.

Most of the value sits inside the product

There's a second cost to the outside-the-product approach, and it compounds. Automation that shuffles data between SaaS tools makes one team slightly faster. Automation built into the matching engine, the onboarding flow, or the review queue changes what the business can charge for and how many people it needs to do it. A connector between two tools can't reach the part where the economics live. That's not a knock on connectors; it's a question of where you point them.

So the argument I'd make to any London team weighing this up is that the decision worth spending time on isn't which tool, it's which failures you're willing to accept and who finds out about them. A process that is right most of the time still needs a person checking every output, which means you've automated the typing and kept the thinking. That's a worse deal than doing nothing, because now you pay for both.

What a good result looks like

A system people leave switched on has a few recognisable traits. You can see its error rate on real data before go-live, not a vendor's benchmark. Edge cases route to a person by design, and someone has decided where that line sits. The inference bill stays predictable as volume grows, because caching and model routing were part of the build rather than an afterthought. And the code sits in your infrastructure, so when the original builder moves on, your own engineers can open it.

None of that is exotic. It is just the unglamorous engineering that a demo skips, and it's the difference between an automation your team trusts and a board they quietly stop watching.

If you want the specifics, the full guide on building AI automation that lives inside your product covers the production package, the evaluation and human-in-the-loop controls, and the questions worth asking before you commit.