How an AI automation project works, stage by stage

The four stages, and roughly when each one lands

Owners are usually more afraid of a six month project that stalls in month two than they are of the price. So the shape of the work is published here rather than explained on a call. Scope changes what goes into each stage, but the order never changes, and neither does the point at which you first see something working.

The audit takes the first week. The first system is live inside a fortnight. The second and third arrive across the second month. By around month six the pieces are connected and the reporting arrives without anyone building it the night before.

1. Days 1 to 5, the audit. We map how the business actually runs. Where enquiries come from, where they die, what your team does by hand, and what your tools will and will not allow. You get a written roadmap whether or not you build with us.
2. Week 1 to 2, the first system live. One named problem, working. Something visible is running before you have paid for anything ambitious.
3. Month 2, the second and third. Booking and reminders, the paperwork that gets retyped most often, and your first real dashboard. Your team is trained on each piece as it lands rather than in one long session at the end.
4. Month 6, an operation. Several systems connected, one place holding what the business knows, and a new capability added each quarter instead of a flat fee for standing still.

What lands on your desk at each stage

Every engagement produces the same written outputs, whichever ownership model you choose. These are the things you can hold, forward to an accountant or hand to a new employee, which matters a great deal more than what was said in a meeting six weeks ago.

Only the last row depends on the model you pick. If you decide to run the system yourself, everything up to handover is identical.

• Audit. A written diagnosis of how the business runs today, a list of the bottlenecks in priority order, an integration report saying what your tools will and will not permit, and a build roadmap with the first system named.
• Build. The working systems, each labelled automated or augmented and connected to your tools. A business brain holding your prices, policies and answers. Test results you can see, and a rollback if anything misbehaves.
• Handover. Written procedures, recorded walkthroughs, live training for the people who use it, admin access in your name, and a document listing every account, key and connection the system depends on.
• Ongoing. Monitoring and fixes, a monthly report showing what the systems did, a named person to call, and a quarterly session where the next capability is added.

The four layers, and why the order matters more than the tools

Fixed process, custom scope. Every build runs through the same four layers in the same sequence, and the sequence is the part that decides whether the thing is still being used a year later.

Context comes first. We load in what your business already knows: your inventory or service list, your prices, your payment terms, your policies and the way your best person answers an objection. That is what stops the output reading like a stranger wrote it.

Connections come second, wiring the system into the tools you already run so it reads real data and takes real actions. We check what a tool actually permits before promising it, because some software genuinely will not let an outside system create or update a record, whatever its sales page says.

Capabilities are third: the workflows themselves, with one named problem solved first and then one piece at a time. Cadence is fourth, meaning what runs on a schedule and a dashboard showing what each piece has actually done for you.

Every workflow is labelled automated or augmented before you approve it

Before a workflow goes live it gets one of two labels, and you see the label before you approve the workflow. Automated means it runs unattended and escalates to a person when something is unusual. Augmented means the machine prepares the work and a person still signs it off.

Writing that down is unglamorous, and it prevents most of the arguments that happen later, because nobody is left guessing whether a human being was meant to be involved.

• Usually automated: instant replies to new enquiries at any hour, qualifying questions and routing to the right person, booking and confirmations and reminders, missed call recovery, after hours capture, receipts, daily briefings, record updates and data tidying.
• Usually augmented: anything published in your name, advert spend changes and budget moves, pricing and discounts and offer approvals, contracts and anything legally binding, a serious complaint or an unhappy client, and the moment a deal is actually being negotiated.

If somebody tells you all of it can run unattended, ask them which part they would put their own name on.

Who does what, so nothing waits on an assumption

Most of the build is ours. The parts that are yours are small, and a project slows down when those small parts are not done rather than when the engineering turns out to be hard.

• Diagnosing where the work and the money leak. We lead. You answer openly.
• Access to tools and accounts. We list exactly what we need. You approve it and grant it.
• Deciding what gets built first. We recommend. You decide.
• Building, testing and connecting the systems. All of it ours, and nothing on your side.
• Anything published in your name. We prepare it. You approve it.
• Telling your team this is happening, and why. We train them. You back it publicly.
• Owning the system, the accounts and the data. Never ours. Always yours, on every model except renting the output, which works differently by design.

When this way of working is the wrong fit for you

This is a written procedure business. Every workflow has a documented procedure, a named owner and a check before it goes live. That is why the output holds up month after month, and it is also why it suits some companies badly.

If you want a price before a diagnosis, the first call will disappoint you. A number quoted before anyone has looked at your tools and your data is a guess, and a guess that has to be corrected in month two is worse than a week of waiting.

If nobody on your side has an hour a week to own this, an owned system becomes an expensive filing cabinet. If your team will work around the written procedure and then hold the system responsible for the outcome, the procedure was the thing you actually bought, and it will not survive contact with the business.

And if the process underneath is broken, automating it makes the wrong thing happen faster and more often. Sometimes the honest recommendation is to delete a step rather than build anything at all. That is the cheapest advice you will get from us and it is frequently the best.

Who you would be working with, and what happens when a workflow misfires

Four people run this, and they are named rather than implied. Moiz Khan owns automation architecture and decides what gets built and how it runs, which makes him the one who refuses a request that would not survive month three. Haad owns growth and client solutions and leads the diagnosis. Ibrahim owns build and workflows and is usually who your team is trained by. Ali owns marketing and sales. None of the four arrived from a consultancy, and the routes in run through medicine, chartered accountancy, media, military school and businesses that had to make payroll.

The company is small and says so. Wobble works from Karachi, is answerable for what it operates, and bills month to month rather than on an annual commitment, so a client who is not getting value can stop and keep the system. Behind that sit 25 engagements in six countries, each published with its figures rather than described in adjectives. It is a deliberately uncomfortable arrangement for a supplier, because a fee that can be cancelled every month is only defensible while the thing is still working.

When a workflow misfires, what happens next was decided before it went live. An automated one that meets a situation outside its scope stops and hands it to a person, with a record of what it was doing attached, so nobody has to reconstruct the morning. An augmented one already waits for human approval and simply does not proceed. A step that fails the same way twice halts rather than retrying, because a loop running unattended overnight costs more than a job that waits until somebody is awake. The honest limitation underneath all of it is that a system cannot recognise a case nobody ever described to it, which is why the stop matters more than the cleverness.

Keeping it in-house is a real option and it deserves a straight answer about when. If somebody in your business enjoys this work, already builds automations, and will still be there in a year, the first one or two systems are within your reach, and the written roadmap out of the audit is enough to act on without us. That roadmap is yours either way. What is harder to hold internally is the fourth month with several systems running at once, when the person who built them has another job to do and a model provider has changed behaviour without announcing it. That month, rather than the building, is what is actually being bought.

Common questions

How long does an AI automation project take?

It depends on how much is being connected, but the shape is consistent. The audit takes the first week. One named system is usually live inside two weeks. The second and third land across month two. By month six a business that keeps going typically has several connected systems and reporting that builds itself. A single automation for one process is much shorter than that.

What happens in the audit, and do I have to pay for it?

The first call is free, always. The audit itself is scoped by the size of the business. A team of one to five people takes a morning, so it is free. Larger than that, with departments and several service lines, takes days of sessions across your team, and it is paid. That rule does not move depending on how keen we are to win the work.

Do we need a technical person on our team?

No. Building, testing and connecting is entirely our side, and your team is trained on the day to day use as each piece lands. What you do need is one person willing to own the thing internally, even if that is only an hour a week, because a system nobody is responsible for slowly stops being used.

What do you actually need from us to start?

Three things. Access to the tools you want connected, which we list by name so you can approve them. Honest context about how the business really runs, including the workarounds. And one clear first problem worth solving. The audit defines the rest, and you get the written roadmap out of it either way.

What if a workflow does something we did not want it to do?

Every workflow is tested before it goes live, you see the test results, and there is a rollback. Anything that carries real consequence is labelled augmented, which means a person signs it off rather than the system acting alone. If something unusual happens inside an automated workflow, it escalates to a human instead of guessing.

Can we start with one process rather than the whole thing?

Yes, and that is the normal way in. One named problem gets solved first, usually the one that is costing the most right now, and nothing else is switched on until that piece is working. Systems are added afterwards one at a time, so there is never a single launch day that everything depends on.