How to automate business processes, step by step.

From a repetitive process to a working automation

Automating a business process means taking work that already happens, writing down how it should run, and using software plus agreed rules to move the routine steps — while a person still handles the exceptions.

This article is the implementation path. It is not a catalogue of workflow ideas. For those, use workflow automation examples. The twelve steps below are a practical order, not a claim that every process needs all of them, or that every process should be automated.

1. Identify repetitive business work

Inventory processes, not software products. Look for repeated tasks, manual data entry, recurring communications, approval requests, routine handoffs, status checks and reporting that someone rebuilds each week.

Write what starts the work, what finishes it, and who is interrupted in between. If you cannot name those three things, you do not have a process yet — you have a pile of jobs.

2. Prioritize opportunities

Compare candidates on frequency, time spent, predictability, business impact, how often mistakes happen, whether the information already exists, how hard the systems are to connect, the risk if something goes wrong, and how much human judgment the work still needs.

Frequent, rule-based processes with clear inputs are usually better first projects than rare, judgment-heavy work. High frequency alone is not enough. A daily task that needs a person to decide should not be first in line.

3. Map the current process

Document the process as it actually runs, not as the handbook says it runs. Capture the trigger, the information required, the systems involved, the people involved, the decision points, the delays, the exceptions and what “done” means.

The playbook How to map a process before automating it is the place for that exercise. This article does not repeat it. Come back here once the map exists.

4. Define the desired outcome

Decide what would count as an improvement before anyone configures software. Typical aims: less manual entry, shorter turnaround, more consistent follow-up, fewer missing handoffs, clearer visibility, or fewer avoidable errors.

Write the outcome in operational terms you can observe. “The business feels smoother” is not a measure. Do not treat a target as a promised result.

5. Check data and system access

An automation can only use information it is allowed to see, in a form it can read. Review the current software, whether a usable API or export exists, access permissions, data quality, missing fields, duplicates, rate limits, authentication, privacy constraints and any hard system restrictions.

Not every system can be connected. Compatibility is assessed during Implementation. If a required field is routinely blank, fix the data habit before you automate around it.

6. Write the automation rules

Translate the map into: trigger, conditions, approved action, and exception or human handoff. Cover the common case and the nonstandard one. A rule that only describes the happy path will fail the first unusual Tuesday.

That outline is illustrative. It does not assume a particular CRM or email product.

7. Define human controls

Decide where the automation must pause. Typical stops: unusual refunds, sensitive complaints, spending approvals, pricing exceptions, missing information, unclear identity and contract commitments.

Different processes have different risk. Appointment reminders and payment releases do not deserve the same checkpoint. Write the stop into the rules before anything goes live.

8. Select the implementation approach

Choose the smallest approach that can complete the process:

• The current software’s built-in automation, if it already can.
• A connection between systems you already use.
• An AI Employee when one defined role owns the work.
• An AI Team when several coordinated roles share the sequence.
• Custom AI Automations when the process crosses systems or rules those options cannot finish.
• Custom Software when people need a new application, not only a workflow through existing screens. Build vs buy helps with that choice.

Custom work is not the default. If a native setting or one Employee covers the job, start there.

9. Build a limited first version

Start with one defined workflow, clear inputs, a manageable number of systems, known approval rules, a testable outcome and documented exception paths. Do not automate every department at once.

A first version that works in one process teaches more than a programme that tries to own the company on day one.

10. Test normal cases and exceptions

A single happy-path demonstration is not enough. Test correct inputs, missing information, incorrect information, duplicate events, failed integrations, permission errors, timeouts, exceptions and the human approval path.

Write down what should happen in each case before you run it. If the automation cannot fail safely, it is not ready.

11. Roll out and measure

Pilot with a limited scope. Train the people who will see the exceptions. Record a simple baseline — time spent, missed steps, or volume handled — then measure the same things after launch. Track errors. Name the owner.

Do not invent a target saving percentage. Measure what you actually care about. The AI Savings Calculator can help estimate the time sitting in repetitive work; it is a planning tool, not a result.

12. Maintain and improve

Automation is not maintenance-free. Software changes, APIs change, business rules change, and permissions drift. Plan for monitoring, escalation review and periodic tests.

AI Build Geeks’ delivery model for work we operate is Implementation, Managed Service and usage through platform credits where applicable. A process without an owner will quietly decay.

Worked example: follow-up after a quote

The example below is illustrative. It is not a documented customer implementation, and it does not assume a particular CRM or mailbox.

Current process

A business sends quotes. Staff remember — or forget — to check outstanding ones. Follow-up timing varies. CRM records are often incomplete, so nobody is sure who is waiting.

Desired process

The business defines what makes a quote eligible, which customers may receive a message, how long to wait, which approved wording can be used, when a person should review, and when the workflow should stop.

Exception conditions

• The customer replies.
• The quote is withdrawn.
• The customer opts out.
• The quote status changes.
• The record is incomplete.
• The conversation needs a sensitive negotiation.

Testing

Before launch, run at least: a complete eligible quote, a quote with missing contact details, a customer who already replied, a withdrawn quote, a duplicate “sent” event, and a case flagged for a person. If any of those cannot be described, the rules are not finished.

Measurement

Useful observations: eligible follow-ups completed, time spent manually checking, exceptions that needed a person, and failed or duplicate actions. Do not treat a conversion-rate lift as a promised outcome.

Product boundaries

Customer Follow-Up is a standardized AI Employee for an appropriate follow-up role. A process that spans several systems or unusual rules may need Custom AI Automations. Those options are not interchangeable and are not automatically connected. The Automation Finder can help you see which conversation to start.

Process worksheet

Copy this into a document and fill it in before you ask for Implementation help. It is a worksheet, not a specification template that guarantees a quote.

Common mistakes

• Automating a process nobody can describe.
• Starting with too many systems at once.
• Ignoring data quality and then blaming the automation.
• Missing exception handling.
• Failing to name an owner.
• Giving the workflow more permissions than the job needs.
• Treating AI output as inherently correct.
• Ignoring maintenance after launch.
• Measuring success only by how many tasks were automated.
• Testing only the happy path.

Those are operational problems, not industry statistics. There is no failure-rate figure on this page because that would be an invented benchmark.

What determines automation cost

Cost follows the work: number of systems, complexity of rules, data quality, whether a connection exists, required approvals, AI or provider consumption, monitoring and ongoing maintenance.

There is no standard automation project price on this page. Custom workflows are scoped individually. AI Build Geeks’ model is Implementation, Managed Service and usage where applicable. Pricing explains that model for catalogue products. It is not a fixed fee for Custom AI Automations. AI Consultancy is the right conversation when the process is still being chosen.

Common questions