A useful first automation project tackles a task you can describe and check. It has a clear starting point, an expected result and someone responsible when things go wrong. The aim is to improve one piece of work before committing to a wider system.
For a business using a mixture of spreadsheets and email, the tempting answer is often to connect everything at once. A better starting point is to examine one task from beginning to end. That shows where a software change would help and where the process itself needs attention.
Choose a task with a visible finish
Consider an enquiry that arrives by email. Someone records the customer details, assigns a colleague, arranges a follow-up and updates a spreadsheet. If those steps are understood, a small system could keep the record, owner and next action together.
Now consider an enquiry that cannot be assigned because nobody has agreed which team handles it. Automatically moving the email will not resolve that uncertainty. The ownership rule needs deciding first. These are illustrative examples, not accounts of client projects.
Write down the normal route and the exceptions
Describe what starts the task, what information is required and how you know it is complete. Include the cases that do not follow the normal route: a missing reference, a duplicate request, a customer changing their mind or an unavailable approver.
A workflow needs somewhere for those cases to go. Specify who reviews them and what they need to see. A process is easier to trust when incomplete work remains visible rather than being treated as successfully finished.
Find the part that repeats
Useful candidates include creating a record from an agreed input, assigning a task using a clear rule, checking a due date or preparing a report from consistent data. Work that changes substantially each time may need a guided screen or a person’s review instead of full automation.
Automation does not necessarily need artificial intelligence. A date check or approval route can usually be described with explicit rules. If the task involves interpreting unpredictable text, consider the additional checking and data-handling requirements before deciding whether AI belongs in the design.
Keep a way to check and correct the result
Agree what should happen when a connected service is unavailable. The workflow may need to retain the pending task, show an error and notify its owner. It should also be clear whether an action can be retried without creating duplicate records or sending a message again.
Important decisions need an appropriate review point. For example, preparing a reminder is a different task from approving a contractual change. Describe those boundaries as part of the requirements.
Decide how you will judge the improvement
Choose a measure linked to the original difficulty. It might be how many times details are entered, how long a report takes to prepare, or how often follow-ups are missed. Record the starting position and review the same task after the change.
Do not assume a particular saving in advance. The result depends on the task, the quality of the information and whether the team adopts the new way of working. Feedback from the people doing the work matters alongside any figures.
Agree the smallest useful first version
Define the users, essential steps, required connections and acceptance checks. Keep optional improvements separate so the first release has a clear purpose. Hosting, access, documentation and maintenance responsibilities also need to be agreed.
StellarStacks develops bespoke systems, portals and workflows for everyday business tasks. Our development approach starts with understanding the work and agreeing priorities.
For more detail, read our FAQs on choosing a first process, or tell us about the task you would like to improve.
