More enquiries and less busywork with AI that fits your business.

Before any tool gets picked you settle three things. None of those questions is technical. Which task costs you time every week, how often does it come up, and how clear is the rule behind it? Once you can answer that, choosing the technology is the easiest part of the project. Do it the other way around and you buy a solution, then go looking for a problem that fits it.

The third question is the one that usually decides the outcome. A task with a clear rule becomes an automation that takes the same path every time. A task where you start hedging while explaining it, because "it depends", needs a model that makes the call case by case. Both are doable, but they are two different builds with very different effort behind them.

An automation follows a fixed order and fits everything that runs the same way each time: an invoice arrives, the data gets read out, accounting receives it sorted. An AI agent gets a goal instead of a sequence and decides for itself which steps to take. And when no off-the-shelf tool fits your data, it becomes custom software that covers exactly your case and nothing else.

The line between the first two matters more than it sounds. An agent gets expensive in places where an automation would have been enough. Which form wins when is spelled out in AI agent or automation.

• Same sequence every time, clear rules: an automation, because it stays traceable and costs almost nothing per run.
• Language, context, case-by-case judgement: an AI agent that reads, sorts and asks back when in doubt.
• Your own data, your own logic, no matching tool: a small application that covers exactly that slice.
• Customers cannot find you although the offer is good: then the work sits with websites and SEO rather than with a model.

The most common cause is not a technical fault, it is a use case nobody looked at closely beforehand. A prototype runs cleanly in the demo because it was fed clean sample data. In daily business you get enquiries without a subject line, invoices as a photo and customers who pack three questions into one mail. That is why the first prototype I build runs on your real data and not on a template.

• The use case is picked too large, so six weeks pass before anybody sees a result.
• Nobody on the team knows what the system does, because the handover was a login and a link.
• The data question gets pushed to the end, although it decides which model you can use.
• There is no way back when the automation gets it wrong, so nobody dares to switch it on.

A project pays for itself fastest when it starts with a single task and covers that one completely. You work out the benefit beforehand by multiplying the minutes per run with the number of runs per month. Putting several tasks in order is covered in which tasks to automate first. What such a first step costs is calculated in what an automation costs.

After that the second use case is usually cheaper than the first, because logins, interfaces and permissions are already in place. That is the real reason to start small: you are not just buying one automation, you are buying the groundwork for the next five.