Start with a task that happens often, follows a reasonably consistent process and has an outcome you can check. Moving complete website enquiries into a CRM, assembling a routine report or creating an internal follow-up task can be better first projects than automating a complicated customer conversation.
The right choice depends on where your business loses time or misses work. Before buying another tool, watch a few real examples of the task from beginning to end. You may find a step to remove, a feature you already pay for, or a small integration that solves the problem.
List the work that keeps coming back
Ask the people doing the administration to record repeated tasks over a normal working week. Capture busy days and awkward cases as well as the easy ones. Seasonal businesses may need a longer sample.
For each candidate, note:
- what starts the task, such as an accepted enquiry or a changed job status.
- where the information comes from and where it needs to go.
- how often it happens and how much hands-on time it takes.
- what someone checks or decides along the way.
- how often information is missing or an exception needs attention.
- what goes wrong if the task is late, duplicated or incorrect.
Be specific. “Do the admin” cannot be scoped. “Create a CRM enquiry and a task for the right team when a valid website form arrives” can be discussed and tested.
Tools can help map larger processes. Microsoft's process and task mining overview describes using records of actual activity to understand steps and find inefficiencies. For a small first project, a shared document and a few observed examples may give you enough information to choose sensibly.
Choose a task you can explain and recover
A good first candidate has a recognisable start and finish. Someone can explain the normal rules, the required information already exists, and a person can deal with exceptions without losing the original request.
Use these questions to compare your shortlist:
- Does it happen enough to matter? Count the work, including interruptions and repeated checking. A short daily task may justify attention before a long annual one.
- Are the rules settled? If two staff members disagree about what should happen, resolve that before encoding the process.
- Can the systems connect? Check the actual subscriptions and supported integrations. A tool appearing in an integration catalogue doesn't prove it supports the action you need.
- Can someone verify the result? Decide which record, message or completed task proves success.
- Can you recover a failed run? Keep the original input, identify what already happened and provide a controlled way to finish the work.
Don't average away a serious problem with a numerical score. An attractive time saving doesn't resolve unclear permission to use the information or the absence of a reliable connection.
If the task involves judgement, consider automating its preparation. Collecting the information for a quote can be a useful first project even when the final price still needs a person.
A fictional shortlist, worked through
Imagine a small maintenance company considering three tasks. These figures are invented to demonstrate the decision, not results from a Right Cyber client.
Website enquiry entry: 40 enquiries a week, three minutes each to copy into the CRM. The form has consistent fields, but some enquiries lack an address. A first workflow could create the record, preserve the original enquiry and put incomplete cases in a review list.
Weekly report preparation: one report, taking 90 minutes to collect figures from two systems. This could be suitable if the figures have stable definitions and both systems provide the required data. First check whether an existing report or export already does enough.
Quoting unusual work: five quotes a week, taking 30 minutes each. It consumes the most time, but the final amount depends on access, materials and judgement. Begin with an information checklist or draft preparation, rather than automatic pricing.
The enquiry process is a sensible first candidate in this example because its input, result and exceptions are clearer. Another business could reasonably choose the report. The method is to compare the actual work and consequences, not assume that one task always wins.
Count the work that remains
For the fictional enquiry process, the current workload is 40 × 3 minutes, or 120 minutes a week.
Suppose a trial shows 30 seconds of checking per enquiry, plus 20 minutes a week dealing with exceptions and monitoring. The remaining work is 40 minutes, giving a potential saving of 80 minutes a week. That is less than claiming the entire two hours disappeared.
These are illustrative assumptions. Measure your own trial. Include time spent correcting mistakes, maintaining connections and helping staff use the new process.
Then compare that benefit with setup work, subscriptions, usage charges and ongoing care. If you put a cash value on freed time, keep it separate from money actually saved. An hour available for customer work doesn't automatically reduce payroll or produce an extra sale.
Time is also only one outcome. A useful automation might make overdue tasks visible or reduce missed enquiries. Choose a measure you can observe, such as the number of valid enquiries without an assigned owner after one working day.
Decide whether AI adds anything
Copying a form's company name into a CRM field usually needs a dependable connection and clear rules. Adding an AI model to that step may add cost and uncertainty without helping.
AI becomes more relevant when the input needs interpretation. For example, it might propose a service category from a free-text enquiry or draft a short summary for staff. Keep the original message available and define what happens when the category is unclear.
Start with a bounded output that somebody can check. An AI-generated summary can be useful without giving the model authority to promise a delivery date, change a price or contact the customer.
Write the first automation brief
You can send this short brief to a colleague or supplier:
- Task and owner: the job to improve and the person responsible for it.
- Trigger: the event that starts a run.
- Inputs and destination: the information required and the systems involved.
- Normal result: the records or actions expected when it succeeds.
- Exceptions: missing information, duplicate requests and cases needing a person.
- Recovery: who is alerted, how they inspect a failure and how work resumes.
- Measure: the present workload and the result the trial must demonstrate.
- Costs and access: available subscriptions, permitted accounts and an agreed usage limit.
Before approving the build, ask for a demonstration using fictional data that includes an incomplete request and a repeated request. The latter should not create duplicate work just because a connection retried.
Run a small trial with a visible stop point
Choose a limited part of the process and agree who can pause it. Keep a manual route available while the team checks the results. Where possible, first send the output to a review list instead of directly acting on it.
Have the builder demonstrate a failed connection in the test environment and show how the team will discover it. n8n supports error workflows that can respond to failed executions, including sending an alert. Those need configuring. A failed-run alert also won't catch every wrong result or an event that never arrived, so compare the incoming work with the completed records.
At the agreed review, keep, adjust or stop the trial based on the evidence. The first useful outcome may be a smaller process than you originally imagined. A clear brief and a measured trial make the next automation project easier to choose and price.