Automation engineering for the work your team still does by hand.
I design, build, and run the automations that take repetitive work off your people: API integrations, workflow automation, browser automation for the systems with no API, document and data pipelines, and AI steps where a rule can’t decide. Engineered like production software — tested, monitored, logged, and documented — so it keeps working long after the person who built it has moved on.
Every company already has automation. A spreadsheet macro someone wrote in 2019. Forty zaps on a personal account. A script on a laptop under a desk that posts the nightly numbers. It all works — until a field gets renamed, an API changes, or the person who built it leaves. Then it stops, nobody is told, and you find out at month-end.
Building an automation is the easy part. Keeping it correct for years is engineering. Automation engineering is the discipline of treating automations as production systems: designed around the real process, tested against real data, safe to retry, watched while they run, and written down so someone else can maintain them.
That’s the work I do. I find the repetitive, rule-heavy work that is costing your team hours, pick the right method for each step — an API call, a workflow platform, a scripted browser, an AI model, or a person’s approval — and ship it with the monitoring and documentation that make it something you can depend on.
What “engineering” means here
- Tied to a number — hours returned, cycle time, error rate, or cost per transaction, agreed before anything is built.
- Built on what you run — your ERP, CRM, inboxes, spreadsheets, and legacy systems, connected as they are instead of replaced.
- Designed for failure — timeouts, bad inputs, and exceptions have a planned path, not a silent stop.
- Owned — every automation has a named owner, a runbook, and an alert that reaches a person.
An automation nobody is watching isn’t saving you time. It’s a manual process waiting to come back on the worst possible day.
The same work, minus the copying and re-keying — moved between systems by automations your team can see and trust.
What automation engineering covers.
- ERP, CRM, HRIS, ticketing, and finance systems
- REST, GraphQL, webhooks, and file drops
- Two-way sync without duplicates
- Approvals, routing, and escalations
- Event-driven and scheduled triggers
- Status visible to everyone involved
- Portals, legacy apps, and vendor sites
- Screen checks, so a layout change fails loudly
- Replaced by an API the day one exists
- Extraction from PDFs, scans, and email
- Validation against your systems of record
- Generated letters, reports, and packets
- Scheduled extracts, loads, and reconciliations
- Data-quality checks that stop bad numbers
- Dashboards and reports delivered automatically
- Classification, extraction, and drafting
- Evaluated before launch and on every change
- Rules and code wherever they are enough
- Shared mailboxes, forms, and file uploads
- Requests matched to customers and cases
- Routine answers sent, the rest queued
- Approvals in Slack, Teams, or email
- Thresholds you set and can change
- Every decision recorded with who and why
- Alerts to an owner, not a dead inbox
- Audits of existing scripts, zaps, and bots
- Ongoing maintenance, or a clean handoff
Built like software, because it is.
Every run on one screen: volumes, failures, and durations, with alerts routed to a named owner.
- Versioned
- Every automation lives in source control, with a history of what changed, who changed it, and why — and a way back.
- Tested
- Run against real samples and the ugly edge cases before it touches production, and again on every change.
- Idempotent
- Safe to run twice. A retry never double-posts an invoice or sends the same email again.
- Resilient
- Timeouts, rate limits, and outages are handled with retries, backoff, and queues instead of a silent stop.
- Monitored
- Every run logged, with a dashboard of volumes, failures, and durations, and an alert to a person when something breaks.
- Secured
- Credentials in a secrets vault, least-privilege service accounts, and no sensitive data in logs that don’t need it.
- Documented
- A runbook for each automation: what it does, what it touches, how to pause it, and how to fix the common failures.
None of this is exotic. It is what separates an automation you can put in front of an auditor from one that works until it doesn’t. For regulated teams, the run log doubles as the audit trail: what ran, on which record, with what result, approved by whom.
API, workflow platform, RPA, or AI: the right method for each step.
- API integration
- When both systems have an API. The fastest, cheapest, and most durable option, so it is the default.
- Workflow platform
- n8n, Make, Zapier, Power Automate, or the automation already built into your CRM or ERP — when your team should be able to see and change the flow themselves.
- Custom code
- Python or TypeScript services when the volume, the logic, or the reliability requirement outgrows a low-code platform.
- RPA
- When the system only has a login page. A scripted browser does what a person would. It is the last resort, because screens change.
- AI step
- When the input is unstructured or the decision takes judgment: reading an email, classifying a document, drafting a reply. Bounded and evaluated.
- Human step
- When the stakes are high or the call is a person’s to make. The automation prepares everything and waits for the approval.
- Left alone
- When the volume is too low or the process too unstable to pay back. I’ll tell you which ones those are before you spend on them.
A process mapped step by step, with the method, the owner, and the exception path marked on each one.
I’m tool-agnostic and have no reseller agreements. If you already own a platform, I build on it; if a hundred lines of code will outlast a subscription, I’ll say so.
One automation, end to end.
-
06:02
Trigger
Three invoice PDFs land in the accounts-payable inbox. Each one is picked up and given a run ID.Sender checked against the vendor list · attachments stored
Started -
06:02
Extract
Vendor, PO number, line items, tax, and totals read from each document.Confidence scored per field · low-confidence fields flagged for review
Extracted -
06:03
Validate
Each invoice matched against its purchase order and goods receipt in the ERP.Quantities, prices, and totals reconciled · duplicates rejected
Checked -
06:03
Write
Invoice one passes the three-way match and is under the approval threshold. It is posted to the ERP.Idempotency key set, so a retry can never post it twice
Posted -
06:04
Exception
Invoice two is 4% over the PO price. It is routed to the buyer in Teams with both documents and the variance.Nothing posted · waiting on a named approver
Needs review -
06:04
Retry
The ERP times out on invoice three. The run backs off, retries twice, and succeeds.No alert needed · the retries are recorded on the run
Recovered -
08:41
Approval
The buyer approves the variance from the Teams message. Invoice two posts with the approval attached.Approver, time, and reason written to the audit trail
Approved -
08:41
Log
All three runs closed. The dashboard shows three invoices, one exception, one recovered failure, zero manual entry.Run history kept for audit · KPI updated
Done
Scripts and zaps versus engineered automation.
Scripts, zaps, and macros nobody owns
Built quickly by whoever had the problem, on whatever account they had. It works, so everyone forgets about it — until an upstream change breaks it and the first sign is a customer complaint or a wrong number in a report.
- No ownerThe person who built it has moved on
- Silent failuresIt stops, and nobody is told
- No testsEvery change is tried out in production
- Tribal knowledgeHow it works lives in one person’s head
Engineered automation
Designed around the real process, including its exceptions. Tested on real data, safe to retry, monitored while it runs, and documented well enough that your team — or the next engineer — can change it with confidence.
- OwnedA named owner and a runbook for each one
- ObservableRun logs, dashboards, and alerts to a person
- TestedChecked on real samples before every release
- MeasuredTracked against the KPI it was built to move
Business process automation, by team.
The rules, the systems of record, and the audit requirements change by industry. I build automation for financial services, healthcare, insurance, legal, and manufacturing teams, with the compliance controls each one needs designed in from the start.
Run in parallel with the manual process until the outputs match — then the manual process is retired.
From audit to automation in production.
Find the work worth automating
I sit with the people doing the work, count the volume, time the steps, and rank the candidates by hours returned against effort to build. You get the list with a number on each line, including the ones not worth doing.
Design the automation and its failure modes
The trigger, the steps, the systems, the method for each step, the exceptions, the approvals, and the KPI — scoped and priced before the build starts.
Build it against real data
Weekly demos on your actual systems and records. The automation runs alongside the manual process until the outputs match, so nothing is switched on by faith.
Go live, monitor, and hand over
Launched with dashboards, alerts, and a runbook. Your team takes it over with documentation and training, or I maintain it — either way it is tracked against the number we agreed on.
Automation engineering questions, answered.
What is automation engineering?
Automation engineering is the design, build, and operation of systems that do repetitive work without a person doing each step. In a business setting that means connecting applications through APIs, automating multi-step workflows, scripting the systems that have no API, processing documents and data, and adding AI where a step needs judgment. The engineering part is what makes it dependable: testing, error handling, monitoring, security, and documentation, so the automation keeps working as the systems around it change.
What does an automation engineer do?
An automation engineer finds the manual, rule-based work in a process, decides what is worth automating, and builds the systems that take it over. Day to day that means mapping processes with the people who run them, integrating systems, writing and testing workflows and code, handling exceptions and failures, setting up monitoring and alerts, and documenting everything so it can be maintained. The job is measured by hours returned and errors removed, not by the number of automations shipped.
What is the difference between automation engineering and RPA?
RPA, or robotic process automation, is one technique: software that operates an application through its screens the way a person would. Automation engineering is the wider discipline, and RPA is one tool inside it. Where a system has an API, a direct integration is faster, cheaper, and far less fragile than a screen-driven bot. I use RPA for the portals and legacy applications that offer no other way in, and replace it with an integration when one becomes available.
Is this industrial automation, such as PLCs and robotics?
No. This is software and business process automation: the work that happens in ERPs, CRMs, inboxes, spreadsheets, documents, and databases. I do not program PLCs or design control systems. For manufacturers I work on the layer above the production line, connecting ERP, MES, quality, maintenance, and document systems so the people around the line spend less time on data entry.
Which processes should we automate first?
Start with the process that is high in volume, follows clear rules, crosses more than one system, and currently depends on someone copying data by hand. Invoice processing, order entry, onboarding, reconciliations, and recurring reports are common first projects. I rank candidates by the hours they return against the effort to build, and I will tell you which ones are too low in volume or too unstable to pay back.
Which automation tools and platforms do you work with?
Whatever fits the job and what you already own. That includes workflow platforms such as n8n, Make, Zapier, and Microsoft Power Automate, the automation built into systems like Salesforce, HubSpot, ServiceNow, and SAP, custom services in Python and TypeScript, browser automation with Playwright, and language models from Anthropic, OpenAI, Google, or open-source models running on your own infrastructure. I have no reseller agreements, so the recommendation is based on your process rather than a license.
Where does AI fit into automation?
AI handles the steps that rules cannot: reading unstructured email and documents, classifying requests, extracting fields, summarizing a case, or drafting a reply. Everything that can be done with plain rules and code is done that way, because it is cheaper, faster, and fully predictable. Each AI step is bounded by validation on either side, tested against a set of real examples, and routed to a person when its confidence is low.
What happens when an automation fails?
It fails loudly and safely. Temporary problems such as timeouts and rate limits are retried automatically with backoff. Bad or ambiguous inputs go to an exception queue with the evidence attached, so a person can resolve them. Anything that cannot recover raises an alert to a named owner. Every write is idempotent, which means a retry cannot create a duplicate record or send a second payment, and every run is logged so you can see exactly what happened.
Who owns and maintains the automations after launch?
You do. The code, the workflows, the credentials, and the documentation live in your accounts and your source control, not mine. Each automation ships with a runbook and a handover session for the team that will run it. If you would rather not maintain it in-house, I offer ongoing maintenance and monitoring, and you can end that arrangement without losing anything.
How long does an automation project take, and what does it cost?
Most builds run six to twelve weeks. A single, well-bounded automation sits at the short end, and a program that spans several systems and teams at the long end. Every engagement is fixed scope and fixed price, agreed after a thirty-minute briefing and a short audit, with weekly demos during the build. Each quote comes with the KPI the automation has to move and what moving it is worth, so the cost always has something to be measured against.
Tell me the task your team hates most.
Thirty minutes. We walk through the process, count what it costs you today, and decide whether it is worth automating. You leave with a design, a timeline, and a fixed price — or an honest “leave it alone.”
