Most SOPs fail at the first fork in the road.

You wrote a perfectly clean process. A new client signs the contract. Onboarding begins. Step one, step two, step three. Beautiful. Then, in step four, the client asks for something the SOP didn’t anticipate, and your team pings you because the document went silent the moment reality got complicated.

That’s not an SOP problem. That’s an If/Then problem.

The If/Then SOP playbook is the methodology we install with clients to turn dead documents into living decision-system SOPs that don’t just describe the happy path but explicitly handle the forks where most processes fall apart. If you’ve ever wondered why your SOPs aren’t reducing the number of questions your team brings you, this is why.

Here’s the part founders hate admitting: a process without decision logic isn’t a process. It’s a wish. And until your SOPs include the If/Then branches that handle the exceptions, you’ll keep being the escalation point for every situation that doesn’t match the template.

Why Most SOPs Die at the First Decision Point

After working through this with dozens of founders, we see the same pattern in nearly every SOP folder we open. The documents are well-intentioned and badly built. They describe what to do when everything goes right. They go silent when anything goes sideways.

That’s why your team still asks you questions even though you wrote the SOP.

A new customer is over the standard credit limit. Does the salesperson approve, escalate, or decline? The SOP says “verify credit.” It doesn’t say what to do when the credit doesn’t verify.

A vendor invoice arrives 12% higher than the agreed amount. Does the bookkeeper pay, dispute, or hold? The SOP says “process invoices.” It doesn’t say what to do when an invoice doesn’t match the contract.

A customer requests a refund 95 days after purchase. Does customer support offer a refund, credit, or escalation? The SOP says “process refund requests according to policy.” The policy doesn’t cover day 95.

Every one of those moments is a fork. And every fork that isn’t documented becomes a question that routes to you. That’s not your team failing. That’s the SOP failing. Linear SOPs work for linear processes, and almost nothing in your business is actually linear.

What an If/Then SOP Actually Is

An If/Then SOP is a standard operating procedure built around explicit conditional logic. Every decision point in the process is documented with the rule that produces the answer, not just the step that needs to happen.

The structure is simple. Wherever a process can branch, the SOP names the branch and the rule.

If the customer is within policy → process the refund as standard. If the customer is outside policy but within 90 days → offer credit equal to the refund value. If the customer is beyond 90 days → escalate to the operations lead.

That’s the whole methodology. Capture the rule, not just the step. Make the decision logic part of the document, not part of the founder’s brain.

The reason most SOPs don’t include this is that the founder hasn’t actually documented the decisions. They live in the founder’s head, in pattern recognition built over years of running the business. The SOP captures the procedure but skips the judgment because it feels too contextual to systematize.

It isn’t. It just hasn’t been put on paper yet.

The 5 Components of an If/Then SOP

Here’s the structure we use with every client when we install the If/Then SOP playbook. Five components. No more, no less.

Component 1: The Trigger

What starts the process? One sentence, naming the event clearly.

Trigger: A customer requests a refund.

Not “refund management” that’s a category, not a trigger. A trigger is a specific event that someone on your team will recognize the moment it happens.

Component 2: The Owner

Who is responsible for executing the process, by role? Never by name.

Owner: Customer support specialist.

By role, because people leave. Roles don’t. An SOP tied to a person dies the day that person quits.

Component 3: The Happy Path

The default sequence is what to do when the situation is standard. Three to seven steps, written as imperatives.

Step 1: Verify the purchase date in the customer record.
Step 2: Confirm the refund request is within the 30-day window.
Step 3: Issue the refund through the payment processor.
Step 4: Send the confirmation email using the standard template.
Step 5: Log the refund in the refunds tracker.

Clean. Direct. Imperative voice. No “the customer support specialist should consider whether to…” just do this, then this.

Component 4: The If/Then Branches

This is where most SOPs die. This is where the If/Then SOP playbook lives.

For every realistic deviation from the happy path, capture the rule that produces the answer.

If the refund request is between 31 and 90 days → offer credit equal to the refund value. Use the credit-offer email template.

If the refund request is beyond 90 days → escalate to the operations lead with a one-line summary of the request.

If the customer escalates or pushes back on the credit offer → offer the refund and flag the account for review at the next operations meeting.

If the refund amount is over $2,500, regardless of date → escalate to the founder before any action.

Each branch has a condition (the “if”) and a rule (the “then”). The rule is specific enough that a competent team member can execute it without judgment calls or know exactly when and to whom to escalate.

This is the part of the SOP that replaces the founder’s brain.

Component 5: The Definition of Done

What “complete” looks like, in concrete terms.

Done: The refund or credit has been issued, the customer has been notified, the action has been logged in the refunds tracker, and any required escalation has been completed.

Without a definition of done, processes leak. Steps get partially completed. Things fall through the cracks. The definition of done is the closing bracket on the SOP.

How to Build Your First If/Then SOP

The temptation when you read this is to go convert every SOP you have. Don’t. Convert one. The hardest, the one your team asks you about most.

Here’s the sequence we walk founders through.

Pick the highest-pain process first. Which SOP do you get pinged about most often? Which one shows up in your text messages, your meeting interruptions, your late-night “can you weigh in on this real quick” requests? That’s the one. The volume is the data.

Map the happy path in 20 minutes. Write the standard sequence first. If you’re spending more than 20 minutes on the happy path, you’re overthinking it. Just capture what normally happens.

List every “yeah but” your team has ever asked. This is the actual If/Then work. For the process you picked, list every exception, edge case, and “what if” your team has surfaced in the past year. Most processes have 4 to 8. Some have more. That list is your If/Then branch list.

Write the rule for each branch. For every branch, write the rule that produces the answer, not the answer to one instance, but the rule that handles every version of that situation. This is the move that does the lifting. The rule is what replaces you.

Test it with someone who didn’t write it. Hand the SOP to someone who has never run the process and have them execute it on a real case. Watch where they get stuck. Every stuck point is a missing branch. Add it.

That’s how you get one If/Then SOP that works. Then you do the next one. Inside three to four months, the highest-pain 10 to 15 processes in your business are If/Then SOPs, and the volume of questions routing through you drops by 70 to 90%.

The If/Then Move That Changes Everything

Here’s the part of the If/Then SOP playbook that founders don’t see coming.

Once you’ve documented the branches for a process, you’ll realize something uncomfortable. A lot of the “judgment” you were applying wasn’t actually judgment. It was just a rule you’d never bothered to write down. You were applying the rule consistently, but you were the only person who had access to it, because it lived in your head.

That’s not judgment. That’s an undocumented decision rule.

The If/Then SOP playbook isn’t about adding bureaucracy to your business. It’s about extracting the operating system that already exists inside your brain and putting it somewhere your team can use it.

You’ve been making these decisions consistently for years. The decisions aren’t the problem. The fact that no one else has the rules is the problem. Once the rules are on paper, decisions can be made without you. That’s the entire move.

What Changes When Your SOPs Have If/Then Logic

Here’s what we see with founders 90 days into running If/Then SOPs.

Their text messages get quieter. Not because their team got smarter, but because the SOPs got smarter. The “quick question, what should we do about X?” texts drop off because X is in the SOP now, with a rule attached.

Their team stops escalating decisions they shouldn’t have been escalating, and starts cleanly escalating the ones that genuinely need the founder. The signal gets stronger because the noise is filtered out.

Their processes survive turnover. When the customer support specialist quits, the next one onboards in days instead of months because the rules are documented, not hidden in the previous person’s pattern recognition.

And the one founder doesn’t expect them to start seeing the business clearly for the first time. Because every undocumented decision rule was a small piece of fog. Get them on paper, and the fog lifts. You see the actual structure of your business’s operations, often for the first time.

You’ve been carrying the decision rules in your head for years. Put them in the SOP. Watch the noise drop.