How to plan your first business automation.

Choose a bounded problem

Start with a repeated hand-off that has an owner and a clear end. For example, an enquiry might arrive by email, need a completeness check, then need assignment to a salesperson. Treat that as one workflow. Replacing your entire sales process is a different project.

Record how the task works today before choosing software. Count a representative set of requests, the time spent handling them, the missed steps and the exceptions. Include quiet and busy periods. These observations become your baseline; they are not promises of future savings.

• What event starts the work?
• Who owns the final outcome?
• What information is required?
• What means the task is complete?
• Which cases must go to a person?

Write the happy path and the exceptions

For an illustrative enquiry workflow, the happy path is: receive the request, save it, check required information, suggest an owner and notify that person. A missing email address should create a review task rather than a fabricated address. A duplicate should not create another sales opportunity. A delivery failure should leave a visible pending notification.

Decide which actions need approval. Preparing a draft and sending a customer commitment have different consequences. Keep pricing exceptions, payment approvals and promises about delivery with the person authorised to make them.

Define access before connecting tools

List the applications involved and the minimum permissions each connection needs. Use a dedicated integration identity where supported. Keep credentials in the hosting platform's secret store, and decide who can revoke or rotate them. Do not paste passwords into a project brief.

Agree how the system identifies a repeated request, where it stores its progress and how an operator can pause it. If a provider times out after accepting an action, a retry may duplicate that action unless the provider supports a shared request identifier or you reconcile the result.

Test one complete workflow safely

Use invented examples in an isolated test environment first. Include a normal request, missing information, duplicate requests, provider failure, denied access and an interrupted run. Confirm that a retry does not silently discard work and that no test message reaches a customer.

For a small pilot, agree the people, records and permitted actions in advance. Keep a manual fallback available. Review the outputs with the team doing the work rather than relying only on a successful technical response.

Measure outcomes and prepare the handover

Compare completed work, handling time, corrections, missed requests and operating cost against the baseline. A quicker process that creates more rework is not automatically an improvement. Record how long the pilot ran and how many tasks were reviewed so small samples are not mistaken for a proven result.

The handover should name the workflow owner, support contact, failure alert recipient, access-review process and recovery procedure. Agree which changes require another approval. Expand only after the first workflow is useful and the exceptions can be handled reliably.

• An agreed scope and acceptance checklist
• A named owner and manual fallback
• Test evidence for normal and failure cases
• Access, retention and recovery instructions
• A baseline and a date to review results