Pick the boring process, not the impressive one
Most automation programmes stall after one project, and the reason is usually the project that was picked. Companies start with the process that sounds most impressive in a meeting rather than the one bleeding hours every week. The impressive one is complex, touches three departments, and produces an ambiguous result that nobody can defend. Pick a boring, high-frequency process instead and you get a number you can point at, which is what funds everything after it.
Rank by frequency times annoyance
Write down every repetitive task your team performs, then score each one twice: how often it happens, and how much of a person's attention it consumes when it does. The top of that list is almost never strategic. It is chasing unpaid invoices, routing incoming enquiries to the right person, copying order details between two systems, assembling the same report every Monday. High frequency and low judgement is the profile you want, because it means the payoff arrives quickly and being wrong occasionally costs little.
Time it before you touch it
Spend a week measuring the current process honestly. How many minutes per instance, how many instances per week, how often does it go wrong and what does fixing it cost. Teams consistently guess badly here, usually underestimating because the work is spread across several people in small pieces. Without this number you cannot tell afterwards whether the automation helped, and you will be arguing from impressions in a room where somebody has a budget.
Map the process as it really runs
The documented version and the actual version are different in every company. Sit with the person doing the work and watch them, including the workarounds they have stopped noticing: the side spreadsheet, the message to a colleague to check something, the manual correction they make every time. Automating the documented version produces a system nobody uses. This is the step that most often reveals the process itself is the problem, which is a cheaper thing to fix than software.
Talk to us about automating a process on WhatsAppFix the data before the workflow
Automation acts on whatever it is given, confidently and at speed. If your customer records live in three places with different spellings and nobody trusts the totals, an automated process will make wrong decisions faster than a person would. Getting information into one reliable place is the least exciting part of the project and the part that determines whether any of it works. Companies that have outgrown spreadsheets usually discover this is the real starting point.
Keep a person on the outcome at first
Run the automation in proposal mode before you let it act alone. It drafts the reply, routes the enquiry, flags the overdue invoice, and a person confirms. You will find the exceptions in the first fortnight, and you will find them before a customer does. Once the confirmation stops changing anything, remove it. Skipping this stage is how companies end up explaining to a client why they received three automated reminders for an invoice they had already paid.
Choose the tool after the process, not before
Once the process is mapped and the data is clean, the build question usually answers itself. Small, changeable, low-stakes processes belong in assembled tools. Anything central to how you make money, carrying your data, or expected to run unattended belongs somewhere you control. That trade-off is worth understanding properly as no-code versus custom software, and if the answer is a system you own, that is what a custom platform is for. It is a decision better made second. Choosing the platform first is how a business ends up bending its operation to fit a tool it picked in a demo.
Written by
Idennex
Strategy-first agency, Istanbul