What the OIL Framework Does: Interrogate, Delete, Simplify, Automate

Why This Matters Now

Most operators treat automation as the solution to process problems. They wire broken steps into Zapier or HubSpot workflows and expect the chaos to stop. It doesn't. The chaos just moves faster and costs more to unwind. A 2023 Gartner report found that over 60% of automation initiatives fail to deliver expected value, and the most common root cause is automating poorly designed processes rather than fixing them first.^[1]

The OIL Framework exists because the sequence matters more than the steps. You can know every lean tool, every workflow platform, every no-code builder, and still produce a bloated, brittle system if you reach for Automate before you've run Interrogate and Delete. This page explains the framework, shows real receipts, and maps OIL to the broader Axis Method that drives every Operations Architect engagement.

The Order Is the Whole Point

OIL is not a checklist you fill out once. It's a discipline with a strict sequence. Skipping a step doesn't save time. It buries the problem one layer deeper, where it costs more to find and fix later.

• Most companies automate first. They wire broken steps into Zapier or HubSpot workflows and wonder why the chaos just moves faster.
• OIL enforces a sequence: you cannot automate what you have not interrogated, and you cannot simplify what you have not deleted.
• Skipping a step does not save time; it buries the problem one layer deeper where it costs more to fix later.
• The principles do their work; the labels do not. OIL is a discipline, not a template you fill out once and file away.
• Every Operations Architect engagement at OAG runs OIL in the first sixty days, before any new tool is introduced or any workflow is configured.

The most common mistake I see in lower-middle-market companies is treating software as a substitute for process thinking. A company buys a new CRM, migrates their broken pipeline into it, and calls that an upgrade. Six months later they're paying for the CRM and a consultant to untangle the mess inside it. OIL stops that before it starts.

Step 1: Interrogate

Interrogate means asking one question about every step in a process: does this need to exist at all? Not "how do we make this better?" The question is sharper than that. "Why does this step exist, and who would notice if it disappeared tomorrow?"

• You're looking for process debt: steps nobody owns, reports nobody reads, approval chains nobody has questioned in three years.
• The question is not "is this step efficient?" The question is "does this step need to be here at all?"
• In a seasonal warehouse running roughly 500 associates (OAG receipt: spirit_halloween.headcount), interrogation surfaces steps that were added by fear or habit, not by function.
• Interrogate produces a list of candidates for deletion. Nothing gets automated from this list. Nothing gets simplified yet. The list just exists.
• Most process audits skip this step and go straight to "how do we improve this?" That question assumes the step deserves to survive. Interrogate does not make that assumption.

Process debt compounds the same way financial debt does. A step that shouldn't exist gets documented, then trained on, then integrated into a workflow, then automated. At each stage the cost of removing it goes up. Interrogate catches it before any of that happens. This is the whole reason it runs first.

My decade of enterprise operations across Amazon, International Paper, Spirit Halloween, Maersk, and Levi Strauss (OAG receipt: cedric.career_summary) showed me the same pattern at every scale: the most expensive steps in any process are the ones nobody questions because everybody assumes someone else owns them. Interrogate puts a name on that assumption and challenges it.

Step 2: Delete. Step 3: Simplify.

Delete and Simplify are paired here because most operators conflate them, and conflating them is how process improvement projects produce systems that are still bloated. They're different operations with different outputs.

• Delete is not optimization. It is removal. If a step survives interrogation but cannot show measurable value, it goes entirely.
• Most operators skip Delete and jump straight to Simplify. That's why their systems stay bloated even after a so-called "process improvement" project.
• Simplify means reducing every surviving step to its minimum viable version: one input, one output, no exceptions without a written reason.
• Together, Delete and Simplify are where the real savings appear, before you spend a dollar on new tools or configuration hours.
• A step that gets simplified but should have been deleted is still waste. Delete first. Simplify what remains.

Delete vs. Simplify: what each step actually does

The savings from Delete and Simplify are real and they show up before any automation budget is spent. A sales team on Salesforce Sales Cloud Enterprise at roughly $2,000 per year per seat (OAG receipt: jps.replaced_tool) had eleven pipeline stages. Interrogate found four were tracked but never acted on. Delete removed them. Simplify cut the remaining seven to four. Savings came to approximately $1,100 per year per seat (OAG receipt: jps.savings), and that was before a single automation ran.

Step 4: Automate (and Only Step 4)

Automation is the reward for doing the first three steps well. It is not the starting point, and it is not where most of the value comes from. The value comes from what you deleted and simplified. Automation just locks in the gains and reduces ongoing manual effort.

1. Confirm the process passed Interrogate, Delete, and Simplify before touching any automation tool.
2. Map the surviving steps to triggers and actions. One input, one output per step.
3. Choose the right tool for what the system actually needs, not the tool with the best marketing.
4. Run the DefaultFail test: if this automation breaks tonight, does the business still function? Build for yes.
5. Document the automation the same day it goes live. The hand-off is the deliverable.

OAG uses named tools here depending on what the system needs: Zapier for workflow triggers, Cloudflare Workers and Supabase for owned infrastructure, Resend for transactional email. The StackOS framework runs the infrastructure side of this. OAG operates its entire stack at $74/month (OAG receipt: oag.monthly_run_cost) on owned infrastructure, not rented SaaS with annual escalators that compound every renewal cycle.

Rented SaaS vs. Owned Infrastructure at the Automate Step

The DefaultFail principle applies directly here. Before any automation goes live inside an Operations Architect engagement, I run a failure scenario: what happens if this breaks at 11 PM on a Friday? If the answer is "the business stops," we redesign before we deploy. Stable beats elegant in this phase.

OIL Inside the Axis Method

OIL doesn't run in isolation. It runs inside the Stabilize and Document stages of the Axis Method, the five-stage engine behind every Operations Architect engagement at OAG.

• Diagnose surfaces the mess: what processes exist, who owns them, where they break.
• Stabilize uses OIL to cut the mess down. This is where Interrogate, Delete, Simplify, and Automate run in sequence.
• Document captures what's left after OIL: the surviving steps, the automation logic, the owner for each output.
• Hand-off delivers the documented system to the operator. We don't stay on retainer to babysit it.
• Compound is where the owner runs the system without us, and the documented processes improve over time.

The hand-off is the deliverable. We don't architect the system and then stay embedded to keep it running. If we're still essential at month twelve, we did our job wrong. The Operations Architect engagement runs $3,000 to $7,500 per month, multi-month embedded, and OIL is the primary diagnostic tool in the first sixty days. That's not a long runway. It forces the sequence to run fast and produce something the operator can own immediately.

Operators who want to run OIL on a single process before committing to a full engagement can start with the StackOS Framework PDF at $29, a self-serve document that walks through the audit and architecture steps. If you need a live session with the system built in real time, the StackOS Build runs $2,000 to $3,500 for a single three-hour session. Both are entry points into the same framework. Visit the OAG home page or the OAG blog to see current receipts and case breakdowns.

What OIL Looks Like With a Receipt

Frameworks are only useful when they produce documented outcomes. Here are two receipts from actual OAG engagements showing OIL running in sequence.

Mobile Mechanic on Jobber

• Tool in use: Jobber Grow at $199/month (OAG receipt: mobile_mechanic.replaced_tool).
• Interrogate: found three redundant scheduling steps. Two existed because the original booking flow was never cleaned up after the owner switched service areas.
• Delete: removed two of the three steps entirely. Neither had a measurable output the business relied on.
• Simplify: condensed the third step to a single form with one trigger.
• Automate: replaced Jobber with an owned stack on Cloudflare and Supabase.
• Savings: approximately $1,500 per year (OAG receipt: mobile_mechanic.savings).

Sales Team on Salesforce Sales Cloud Enterprise

• Tool in use: Salesforce Sales Cloud Enterprise at roughly $2,000 per year per seat (OAG receipt: jps.replaced_tool).
• Interrogate: eleven pipeline stages. Four were tracked in the CRM but never informed a decision or triggered an action.
• Delete: removed all four inactive stages.
• Simplify: cut the remaining seven stages to four, each with a clear owner and a documented next action.
• Automate: rebuilt the pipeline logic on owned infrastructure.
• Savings: approximately $1,100 per year per seat (OAG receipt: jps.savings).

The pattern is identical across both receipts: Interrogate before you build, Delete before you Simplify, Simplify before you Automate. We don't install. We don't add. We cut. If you want to understand what counts as operational waste before running OIL, or how OIL compares to lean and Six Sigma methodologies, the OAG glossary covers both. You can also read more about operational excellence as a discipline and where OIL fits inside it.

How OIL Compares to Other Process Frameworks

OIL is not a reinvention of lean or Six Sigma. It's a tighter, faster sequence designed for lower-middle-market operators who don't have a six-month runway for a methodology rollout. Here's how it compares to the two frameworks most often cited in the same conversation.

Lean and Six Sigma are serious disciplines with real results at enterprise scale. The problem is that lower-middle-market operators don't have a full-time continuous improvement team, a certified Black Belt on staff, or a six-month project cycle. OIL runs in sixty days inside an Operations Architect engagement and produces a documented, handed-off system the owner operates without outside help.

Sources

1. Gartner. "Why Automation Projects Fail to Deliver Value." Gartner Research, 2023. https://www.gartner.com/en/information-technology/topics/automation.
2. American Society for Quality. "Six Sigma Black Belt Certification." ASQ, 2024. https://asq.org/cert/six-sigma-black-belt.

OAG receipts cited

• cedric.career_summary
• oag.monthly_run_cost
• spirit_halloween.headcount
• jps.replaced_tool
• jps.savings
• mobile_mechanic.replaced_tool
• mobile_mechanic.savings