Watch the task before choosing the tool
Write down what happens during a normal instance of the task. An enquiry arrives, someone checks whether the details are complete, a row is added to a tracker, and a team member receives a notification. Record the actual steps, including the little decisions people make without thinking about them. Those decisions often explain why an apparently simple workflow is difficult to automate.
For a few working days, note how frequently the task occurs and roughly how long it takes. Separate handling time from waiting time. A process that takes two days because someone must approve it has a different bottleneck from a process that requires twenty minutes of copying. Automating the copying will not remove the approval delay.
Define a trigger, a rule and a result
Describe the workflow in one sentence: when a valid project enquiry arrives, create one record and notify the person responsible. Then define “valid”, “one record” and “responsible”. Which fields are required? What identifies a duplicate? Who takes over when the usual owner is away? Precise rules are easier to maintain than assumptions hidden inside a script.
Choose a tool only after that description is clear. A form service, an automation platform or a small script may all be suitable. For example, Google Apps Script supports installable triggers for certain events and schedules. Its documentation also explains that these triggers run under their creator’s account and are subject to restrictions. Account ownership belongs in the design.
Plan the unsuccessful path
Real inputs are uneven. A customer leaves a field empty, a service times out, or the same event arrives twice. Decide which failures can be retried and which need attention. If a repeated attempt can send another email or create another order, record a stable identifier before making that action repeatable.
Keep an activity log that answers three questions: what arrived, what happened, and what needs someone to act. Avoid putting unnecessary personal information into that log. An error message such as “notification failed for enquiry 123” is more useful to an operator than a silent failure, and may be safer than copying the entire enquiry into another system.
- Reject or flag incomplete inputs before changing records.
- Recognise repeated events so they do not create duplicate work.
- Limit retries and tell an owner when they are exhausted.
- Keep a manual way to complete the task if the workflow stops.
Keep judgement where it is useful
Some tasks are good candidates for preparation rather than automatic completion. A system can draft a response, gather invoice details or flag an unusual submission while a person makes the final decision. This is especially useful when an error would be expensive or when the right answer depends on context that is missing from the input.
In an illustrative lead-handling workflow, automation might collect the enquiry, assign a reference and prepare a summary. A person then decides whether the project fits and writes the reply. This can reduce repetitive administration without pretending that a rule knows whether the customer and the business are a good match.
Run it beside the old process first
Test with normal inputs, missing values, repeated submissions and a deliberately unavailable destination. For an initial period, compare the automated result with the existing process before relying on it. Choose a clear owner and write a short recovery note: where to see failures, how to pause the workflow and how to finish outstanding work.
Review the result using time saved, corrections required and missed work. Count the time spent maintaining the automation too. If a small workflow is dependable and the benefit is visible, expand it one step at a time. If the rules keep changing, improve the underlying process before adding more connections.