Process automation: a practical guide for founders and CTOs

Process automation means replacing a sequence of repeated human steps with software that performs them the same way every time. That is broader than it sounds. A Salesforce Flow that routes a new lead is automation. A Python script that pulls invoices from an API and reconciles them against your ledger is automation. A Terraform pipeline that provisions infrastructure on every merge is automation. The common thread is a defined trigger, a defined set of actions, and a predictable outcome you no longer have to babysit.

It helps to be clear about what it is not. Automation is not the same as building a product feature, though the two often overlap. It is not a substitute for fixing a broken process: if your quote-to-cash flow is chaotic because nobody agrees who approves discounts, automating it just makes the chaos faster. And it is emphatically not a one-off. Every automation you deploy becomes a small system you own, with dependencies, failure modes, and a maintenance cost. That last point is the one founders underestimate most.

The useful mental model is a spectrum. On one end sit deterministic, rules-based automations: if X happens, do Y. These are cheap, reliable, and boring in the best way. On the other end sit judgment-heavy tasks where the rules are fuzzy or the inputs are unstructured text, images, or free-form documents. Historically those resisted automation entirely, which is where large language models now change the calculus. Most real-world automation lives somewhere in between, and the skill is knowing which parts of a process belong to which end of the spectrum before you write a line of code.

Good automation candidates share a profile: high frequency, clear rules, structured inputs, and a real cost when done by hand. Start by listing where your team actually spends repetitive time. The fastest way to surface these is to ask three questions across departments. Which tasks do people do more than a few times a week? Which tasks follow the same steps every time? And which tasks, when someone forgets them, cause a customer complaint, a missed renewal, or a compliance gap?

The answers cluster in predictable places. Lead routing and follow-up creation. Invoice and payment reconciliation. Onboarding checklists that fire when a deal closes. Data entry that copies the same record from one system into another. Report generation that a person assembles by hand every Monday. Document generation, where a template gets filled from structured data. These are the boring, high-volume flows where automation pays back fastest, and they are usually the ones nobody wants to own manually anyway.

Be equally deliberate about what to leave alone. A process that runs twice a year, or one where the rules change with every case, is a poor candidate. The engineering cost to encode all the exceptions can exceed a decade of doing it by hand. A rule of thumb we use: if you cannot write the decision logic down as a flowchart a new hire could follow, the process is not ready to automate yet. Automate it in your head first, on paper, and only reach for code once the steps are stable. Premature automation of an unstable process is one of the most expensive mistakes we see, because you pay twice: once to build it and again to rebuild it when the process shifts.

Once you have a list of candidates, resist the urge to build the one that is most technically interesting. Prioritize by return. The calculation does not need to be precise to be useful. Estimate the hours a task consumes per month, multiply by a loaded hourly cost, and weigh that against the cost to build and maintain the automation. Then add the harder-to-quantify factors: error reduction, faster response times, and the cost of the task simply not happening when a person is on holiday.

A simple way to rank is a two-axis view: value delivered against effort to build. The top-left quadrant, high value and low effort, is where you start. A Salesforce Flow that assigns leads and posts to Slack might take a day to build and save hours a week forever. That ships first. The high-value, high-effort work, like a custom integration between your ERP and your CRM, goes on the roadmap with a real budget. Low-value work is deferred regardless of how easy it looks, because every automation carries ongoing cost.

Be honest about that ongoing cost, because it is where naive ROI math falls apart. An automation that touches an external API will break when that API changes. One that parses a document will misfire when the document format shifts. Budget for maintenance from day one, and factor the vendor's stability into your build-versus-buy decision. For scoping context: a focused automation project sits well below the range of a full custom MVP, which we quote at roughly EUR 25,000 to 40,000 for a simple build. Many high-value automations are a fraction of that, which is exactly why prioritizing the quick, durable wins first produces the best return on your budget.

If your process lives in Salesforce, the platform gives you three main tools, and choosing correctly matters more than most teams realize. Flows are the declarative, no-code-first option. They handle the large majority of business automation well: record-triggered logic, screen-based guided processes, scheduled batch actions, and multi-step orchestration. Our default advice is to reach for a Flow first. It is maintainable by an admin, it is visible in the UI, and it does not require a developer to change a business rule six months later.

Apex, Salesforce's programming language, is where you go when Flows hit their limits. That happens with genuinely complex logic, bulk operations across large data volumes, callouts to external systems that need careful error handling, or anything requiring transaction control that the declarative tools cannot express cleanly. Apex is powerful but it is code: it needs tests, it needs a deployment process, and it needs someone who can maintain it. The mistake we see is teams jumping to Apex for things a Flow handles, creating a maintenance burden they did not need. The opposite mistake, forcing a Flow to do what clearly wants to be Apex, produces unmaintainable spaghetti with dozens of decision elements.

Lightning Web Components (LWC) enter when the automation needs a custom user interface: a guided data-entry experience, a bespoke dashboard, or an interactive tool embedded in a record page. LWC is front-end engineering inside Salesforce, built with modern JavaScript. A healthy Salesforce automation strategy usually layers all three: Flows for the bulk of the orchestration, Apex for the heavy or integration-critical logic, and LWC where users need an interface the standard platform cannot give them. The governance principle that keeps this from decaying is simple: keep business rules where an admin can find and change them, and reserve code for the things that genuinely require it.

Most automation eventually crosses a system boundary, and that boundary is where brittle automations are born. The core patterns are worth naming. Synchronous API calls are the simplest: system A calls system B and waits for a response. They are easy to reason about but they couple the two systems tightly, so if B is slow or down, A stalls. Event-driven or webhook patterns invert this: system B tells system A when something happens, which decouples them and scales better, at the cost of more moving parts. Batch pipelines process data on a schedule, which suits reporting and reconciliation where near-real-time is not required.

The engineering that separates a robust integration from a fragile one is all in the failure handling. Real systems return errors, rate-limit you, time out, and occasionally send the same message twice. An integration that assumes the happy path will corrupt data the first bad day it has. The non-negotiables we build in: retries with backoff for transient failures, idempotency so a repeated message does not double-charge a customer or duplicate a record, dead-letter handling so failed items surface instead of vanishing, and logging you can actually search when something goes wrong at 2am. These are unglamorous and they are the entire difference between an automation you trust and one you have to check by hand anyway.

Data pipelines deserve the same rigor. Moving data between PostgreSQL, a CRM, and an analytics store sounds like plumbing, but schema drift, partial loads, and silent type mismatches quietly poison downstream decisions. Validate data at the boundary, fail loudly rather than silently dropping rows, and monitor the pipeline as a first-class system with Prometheus and Grafana or the equivalent. The stack we reach for, TypeScript or Python with Docker and a proper CI/CD pipeline, exists precisely so that integrations are testable and reproducible rather than a script on someone's laptop that only they understand.

The last few years added a genuinely new capability: automating tasks that require reading unstructured input and making a judgment. That is real, and it changes what is automatable. But the temptation to put a large language model in the middle of every workflow is a trap, and telling the two cases apart is now a core engineering decision. The honest heuristic is this. If the task has clear rules and structured inputs, use plain rules. They are cheaper, faster, fully deterministic, and they never hallucinate. A lead-routing rule based on country and company size should never involve an LLM.

AI earns its place where the input is messy and human judgment used to be mandatory. Classifying free-text support tickets by intent. Extracting fields from PDFs and emails that arrive in a hundred different formats. Summarizing a long document into a structured record. Drafting a first-pass response that a human reviews. These were previously impossible to automate reliably, and models from OpenAI, Anthropic, or an open-source option running on Ollama now make them tractable, often via a RAG pipeline that grounds the model in your own data. For EU businesses, this is also where the EU AI Act and GDPR enter the picture, which is why we default to hosting options in EU regions and open models where the data sensitivity demands it.

The pattern that works is a hybrid: use deterministic rules for the deterministic parts, and reserve the model for the specific step that needs judgment, always with a validation layer and, for anything consequential, a human in the loop. Never let an LLM's raw output trigger an irreversible action unchecked. Treat it as a very capable but occasionally wrong assistant, wrap its output in the same error handling you would give any unreliable external service, and you get the upside of AI without betting your data integrity on a probabilistic system. The processes that break are almost always the ones that trusted the model too much, too early.