# When manual processes and automation belong together > Practical criteria for deciding what to automate and what to keep manual: human judgment, exceptions, unstable rules, and what the data actually says about it. - Author: Marlon Trettin - Published: 2026-06-23 ยท Updated: 2026-08-24 - Language: en - Canonical: https://yowpi.com/en/blog/when-manual-processes-and-automation-belong-together --- Keeping manual steps alongside automation makes sense when the process changes often, depends on human judgment, handles exceptions, or is still being validated. Automation earns its place on what is repetitive, stable and high volume. Mature operations run both modes and revisit that boundary on a schedule. ## TL;DR - Full automation is the wrong goal for most operations. The right criterion is the nature of the task: volume, stability of the rule and cost of the error. - Manual steps are justified where there is judgment, frequent exception, an unstable rule, or an initiative still in validation. - Employers estimate that 47% of work tasks are still performed mainly by people, and the 2030 projection splits work into near-equal thirds between humans, technology and the two together, per the [Future of Jobs Report 2025](https://reports.weforum.org/docs/WEF_Future_of_Jobs_Report_2025.pdf). - Immature, fragmented processes have appeared for four consecutive editions as the top barrier to automation in [Deloitte's global survey](https://www.deloitte.com/us/en/insights/topics/talent/intelligent-automation-2022-survey-results.html). Automating chaos only speeds up the chaos. ## Why is full automation usually the wrong goal? The maxim "everything that can be automated should be" works well on a conference stage and badly in an operation. Automating without judgment produces rigid systems that cost a lot to maintain and drift away from the reality of the people using them daily. Every automated rule is a frozen decision: if the context changes and the rule does not follow, the system starts enforcing a process that no longer fits. The numbers give that limit a shape. In the World Economic Forum's [Future of Jobs Report 2025](https://reports.weforum.org/docs/WEF_Future_of_Jobs_Report_2025.pdf), employers estimate that 47% of work tasks are currently performed mainly by people, 22% mainly by technology and 30% by a combination of the two. The projection for 2030 splits work into three near-equal thirds. Even on the most aggressive adoption horizon, a third of tasks stay with people and another third depends on people and machines working together. From that comes the practical conclusion: the useful question is not "how do we automate everything", it is "where does automation cut errors and free people for what needs judgment". ## When is keeping a step manual the right call? Five situations justify holding automation back, temporarily or permanently. - **Rules that change often.** In a context of unstable regulation, a volatile market or costs under revision, the automation you build today goes obsolete before it pays for itself. - **Tasks that depend on judgment.** Non-standard risk analysis, negotiation, a credit decision at the edge of policy. Where the criterion is qualitative, a person decides better than a rule. - **Initiatives still in validation.** A new process starts manual. Running the first few dozen cases by hand reveals what the automated version needs to cover and avoids investing in a flow that is still going to change. - **Exceptions and outliers.** Every automatic system meets situations it did not anticipate. Without a manual route for handling them, the exception jams the whole queue. - **Limited budget.** When you cannot automate everything, the money goes where the return is clear. The rest waits, and that is fine. ![Team gathered around a table covered in sticky notes, printed charts and laptops, with a tablet in the middle showing indicator dashboards](/blog/quando-faz-sentido-manter-processos-manuais-e-automacao-juntos-1.webp) The five scenarios share one characteristic: the manual step there is an architecture choice, with a defined role inside the flow. Well placed, it protects the operation from rigidity and from the domino effect of exceptions. ## Why is hybrid the normal state rather than a transitional one? Because the systems around the process are not connected either. MuleSoft's 2025 Connectivity Benchmark, built from 1,050 IT leaders worldwide, found the average enterprise running [897 applications with only 29% of them integrated](https://www.salesforce.com/blog/mulesoft-connectivity-benchmark-2025/). Where systems do not talk, a person is doing the talking, and that person is a manual step whether or not anybody drew it on a diagram. Read alongside the WEF figures, the picture is consistent: paper, spreadsheet and system share the same routine in most operations, and will for a long time. The less obvious advantage for a company in that position is that the boundary between manual and automatic can still be drawn deliberately, instead of inherited from automations nobody remembers the reason for. ## How do manual and automatic coexist in practice? Picture a mid-sized solar energy integrator. The sales team runs each customer's feasibility analysis in a spreadsheet: consumption, roof condition, shading, credit profile. Every case has particularities, and the engineer adjusts the assessment based on what they saw on the site visit. Forcing that step into an automatic flow would produce assessments that are too standardized, and immediate resistance from the people who know the subject. The hybrid design resolves the impasse: the feasibility analysis stays manual, but its result feeds an automated flow that generates the proposal, issues the contract and records the sale in finance. The company keeps flexibility where judgment matters and gains standardization and traceability across the rest of the flow. Over time the analysts themselves notice which parts of the assessment repeat and ask to automate one more piece, now knowing exactly what the automation has to cover. ![Illustration of two headset agents on opposite sides of a monitor displaying a smiling robot, surrounded by workflow icons](/blog/quando-faz-sentido-manter-processos-manuais-e-automacao-juntos-2.webp) That movement, from validated manual to stable automatic, shows up in real projects. In the [UniTrust case](/en/cases/unitrust), a US insurance brokerage, the policy automations grew on top of routines the team already ran and understood day to day. ## How do you decide what to automate first? Four questions order the queue. - **Where do manual errors concentrate?** Repeated typing, copying data between systems, calculating in a spreadsheet. Automate those first. - **Has the rule been stable for months?** If it changes weekly, run it by hand until it settles. - **Does the step consume time without requiring a decision?** Record creation, notifications, report generation, integrations between systems and simple approvals are obvious candidates. - **Is the team ready?** Gradual adoption holds better than a hard switch. Deloitte's [intelligent automation research](https://www.deloitte.com/us/en/insights/topics/talent/intelligent-automation-2022-survey-results.html) adds a warning: immature and fragmented processes were named the top barrier to automation in the survey's last four editions. Automating a process nobody mapped just moves the disorganization somewhere it is harder to see. Mapping comes first, and the guide on [7 ways to map hidden bottlenecks](/en/blog/7-ways-to-map-hidden-bottlenecks-in-your-operation) shows where to start. In the other direction, these stay manual by default: strategic decisions, service that needs context, complex validations, and prototyping new flows. ## What keeps a hybrid system healthy? - **A documented boundary.** Record what is manual, what is automatic and why. Without that record the rule becomes oral legend, and every departure takes a piece of it. The practices in [documenting and versioning corporate automations](/en/blog/how-to-document-and-version-corporate-automations) apply to the manual steps too. - **An exception metric.** If an automatic flow starts generating more and more cases for manual handling, the rule has aged. Time to revisit. - **Listening to whoever operates it.** The user notices before any report does when an automation is getting in the way rather than helping. - **Periodic review of the boundary.** What was manual because of instability may now be mature enough to automate. The reverse happens too, and returning a prematurely automated step to manual is a sign of operational maturity. None of these requires sophisticated tooling. They require consistency: one review a quarter keeps the boundary honest. ## Frequently asked questions **Are manual processes a sign of being behind technologically?** Not when it is a conscious, documented decision. Human judgment, frequent exceptions and unstable rules are legitimate reasons for a manual step to exist. The problem is manual by inertia: the step nobody decided to keep, only nobody questioned. **Wouldn't automating a messy process help organize it?** Generally no. Automation executes the rule it receives. If the rule is confused, the result is confusion at higher volume and with less visibility. Stabilize and standardize first, automate after. The Deloitte data cited above names that mismatch as the most common barrier. **How do I know when a manual step is ready to automate?** Three signals usually coincide: volume grew until it became a bottleneck, the rule has been stable for months, and the people who run it are asking for the automation. When the request comes from the team itself, adoption stops being a problem. ## Next step Defining the boundary between manual and automatic is an architecture decision, and every operation has its own. An Operational Architecture Diagnostic is a 30 minute conversation to map where your operation jams and which boundary makes sense for the stage it is in. [Book a conversation](/en/contact).