What is an AI audit, and what should an Irish business get out of one?

An audit worth the time works through 5 layers, and the order matters because each one changes what you notice in the next.

It starts with the workflow: every task that repeats, who touches it, how often, how long it takes, and what happens to it when that person is on holiday. Almost everything else follows from this, and it is the layer people describe least accurately, not through any dishonesty but because work you delegated 3 years ago tends to stay frozen in your head exactly as it was when you handed it over.

Then the tools. Which systems hold which data, which of them overlap, and where information gets retyped from one into another. Retyping is the clearest signal there is. Every instance marks a connection that was never made, and the staff have usually built a workaround around it that nobody upstream knows about.

Then the data itself, which is really a question about trust. There is normally a system of record on paper and a different one in practice, and the gap between the two is where reporting quietly goes wrong.

Then the handovers. Work passing between people is where things get dropped, and those points are invisible on any org chart because they are not anybody's job. They are the gaps between jobs.

Last, the risk. Which steps need a person to approve them, which decisions software should never make alone, and who gets the call when something goes wrong at 6 on a Friday. Suppliers who skip this layer are the ones who later describe an outage as an edge case.

You can judge an audit by what it asks. If none of these come up, the mapping was shallow.

Which task would cause the most damage if the person who does it left tomorrow. What gets retyped from one system into another, and how many times a week. Which enquiries arrive outside working hours, and what happens to them now. What you rebuild by hand every month that looked automatic when you bought the tool. What somebody has already tried to automate here, and why it got switched off. And what must never happen without a person seeing it first.

The last 2 carry the most weight. A previous failed automation tells you where trust was broken and what the team will quietly resist, which is the single best predictor of whether anything new gets adopted. The approval question surfaces where the risk sits in your own words rather than the supplier's assumptions, and those answers become the escalation list. The escalation list is what the build gets judged on 6 months later.

A document, rather than a feeling that the call went well.

It should name the systems worth building in priority order, with the dependencies and the scope boundaries, so you can see what has to happen before what. And it should be specific enough to take to a different supplier tomorrow, which is the real test of who it was written for. Ours arrives within 24 hours and is yours whether you hire us or not.

It should also name what to leave alone. Every business has work that looks automatable and is not, usually because the volume is too low, the exceptions arrive too often, or the relationship depends on a person doing it. An audit with no exclusions has not looked closely enough to have formed an opinion.

A sales call opens with capability. An audit opens with your Monday.

If the first 10 minutes go on what the supplier can build rather than on how your week runs, the conclusion was written before the call started and the rest is a demonstration. Timing gives it away too. A sales call names a tool early, because the tool is the product. An audit refuses to name one until the mapping is done, because until then the requirements are unknown and any recommendation is a guess with a logo on it.

The last signal is willingness to say no. Somebody who has done this work before will tell you in the first conversation that a system is the wrong purchase, if it is, and there are more questions worth asking before you sign anything.

Three things surface again and again, across sectors that otherwise have nothing in common.

Enquiries that arrive outside working hours and get answered a day late, if at all. Reporting rebuilt by hand every month from the same 4 sources, arriving too late to act on. And a process living entirely in one person's head, which nobody notices until that person takes annual leave and the week falls over.

The hours attached to these are almost always larger than expected, because each instance on its own is small. Stuntworxelite were losing 4 to 5 hours a week to confirmations and roster work before the build, which came to more than 40 admin hours across a season, with 500 confirmations handled automatically afterwards.

The total is not really the point. The number that changes a decision is the specific hour, on a specific person's week, that you can put your finger on.

Paid audits exist and some are excellent, particularly at a scale where the mapping genuinely runs to weeks of work. The risk with a paid one is that the document becomes the product, and documents that are products tend to stay comfortably abstract.

The Otomatic Systems Audit is free and runs 30 minutes, which carries its own risk worth naming. A free audit is a sales conversation unless the roadmap is genuinely yours to keep. Ours is, and that is the only reason the format works at all.

Because it is free it carries no guarantee, since there is nothing to refund. Every paid build does. If what we deliver is not measurably changing how you work, you get a full refund or we keep working at no extra cost until it does, and the choice is yours rather than ours.

Track your own time for 5 working days in half-hour blocks. Not for anybody else's benefit and not to show anyone. The point is that you will notice things you stopped seeing years ago, and the conversation gets sharper for it.

Bring whoever actually does the admin. Owners consistently underestimate the number of steps in work they handed over, and the person doing it will name the workaround in 30 seconds flat.

Then book it, or send over the 5 tasks that repeat most often and we will start from there.