Make

Workflow automation pays for itself twice: once when a build removes manual steps from a client process, and again when the same validated workflow is maintained, monitored, and extended under retainer. Agencies that treat each build as a one-off project capture the first payment and miss the second, which is where margin actually compounds. The strategic question is not whether to adopt the category but how much of a client's process inventory you can convert into owned, monitored workflows before someone else does.

Exception Path Inventory is the practice of pricing a workflow by the branches it must handle, not the volume it processes. A trigger that fires 4,000 times a month on the happy path is cheap; the same trigger with eleven exception branches (refunds, partial payments, duplicate CRM records, missing tax IDs) is where delivery hours actually go. Agencies that scope from volume alone win the build and lose the retainer, because every unmodeled branch becomes unpaid maintenance. Before quoting, list each branch, who owns it after launch, and what a silent failure costs the client. The category description puts exception paths and ownership after launch alongside volume and error cost for exactly this reason. A concrete case: a lead-routing flow built in Make can run cleanly for weeks, then a single malformed form submission stalls the queue until someone notices. Claude Haiku 5.5 at $0.10 per million input tokens makes classification of those edge cases affordable, but only if the branches were enumerated during scoping.

Workflow automation platforms connect systems through triggers and actions, but agencies often pitch automation before mapping the client's actual process landscape. The Process Inventory Before Automation framework flips that order: model expansion revenue from a documented inventory of the client's workflows, not from platform assumptions. Before building any integration, catalog every manual step, its volume, error cost, and exception path. This inventory reveals which automations deliver immediate ROI and which are traps. It also uncovers adjacent workflows that justify a retainer for ongoing maintenance. For example, an agency using Make or Zapier might find that a client's lead routing automation has a fragile exception path requiring weekly manual fixes. Fixing that path first builds trust, then the inventory justifies expanding into reporting or CRM sync workflows. Agencies that skip the inventory risk under-scoping projects and leaving expansion revenue on the table.

The Automation Debt Ledger framework treats every workflow automation as a liability with ongoing carrying costs, not just a one-time build. Agencies often win integration projects by automating a client's manual steps, then discover that each workflow carries hidden debts: monitoring overhead, exception-path handling, platform version updates, and ownership ambiguity after launch. The ledger balances these recurring costs against the initial time saved. For example, a client's lead-routing automation in Zapier may save 10 hours weekly, but if the agency must spend 4 hours monthly debugging failed runs and updating API connections, the net value shrinks. The framework forces agencies to price maintenance into retainers and to audit workflows quarterly, retiring those whose debt exceeds their savings. This mirrors the 87% surge in AI content cleanup jobs, where unmonitored automation creates downstream remediation costs that erode margin.

Map the client's process inventory, exception paths, and post-launch owner before writing a single trigger, and price the retainer from that inventory rather than from the category's assumed demand.

Treat every workflow automation as a retainer with a named client owner, and refuse the build if neither exists.

IF a client can name at least three recurring processes with measurable volume, a defined owner, and a tolerable cost per failure, THEN price the work as a managed workflow retainer with monitoring and exception handling included. IF the request is a single connection between two systems with no named process owner and no error budget, THEN scope it as a fixed-fee integration build and hand over documentation at launch.

The choice tracks the client's process inventory, not the platform's feature list. Breadth-first shops with non-technical operators should price Zapier against expected monthly run volume before signing a retainer, while Make suits delivery teams that need visual logic across many steps and n8n only pays off when an engineer owns the deployment after launch. Model expansion revenue from validated workflows you can name, because a platform swap mid-retainer costs more than the license difference.

A productized engagement that maps a client's process inventory, ships two to four validated event-driven workflows, and hands over monitoring and ownership so the work converts into a monthly maintenance retainer.