Why Marketing Automation and Support Automation Need Different Approval Rules

The question nobody asks before they automate

When an owner-operator sets up automation for the first time, the instinct is to treat all tasks the same: either you trust the AI or you don't. But that framing misses the actual risk structure of the work.

Self-Driven Marketing and Self-Driven Support are both functions Koira can run. Both live in the same platform, share the same training interface, and output into the same approval queue. But they are not the same kind of work — and treating them identically when you configure your gates is one of the most common and costly mistakes in small-business automation.

This post is about the single variable that separates them: blast radius.

What blast radius actually means

Blast radius is the number of customers affected if a single automated output goes wrong.

A marketing output — a blog post, a social caption, a product schema update — is typically broadcast. It goes to everyone who visits your site or sees your feed. But it's also largely impersonal and reversible. A clunky blog post doesn't damage a specific relationship. You can edit it, delete it, or let it quietly age off the front page. The reader who encountered it probably won't remember it tomorrow.

A support output — a reply to a refund request, a response to a one-star review, a DM to an angry customer — is targeted, personal, and often permanent in the recipient's memory even after you correct it. The customer who got a robotic, wrong, or tone-deaf reply will remember it. They may screenshot it. They may escalate. They may leave.

The blast radius of a bad marketing output: diffuse, low per-person impact, high volume. The blast radius of a bad support output: concentrated, high per-person impact, low volume.

This single asymmetry should drive every gate decision you make.

How Self-Driven Marketing gates should work

Marketing automation is where you should be moving fastest toward L4 and L5 autonomy — where the system runs end-to-end and you're spot-checking rather than approving every output.

Here's why: the output of marketing automation is almost always a template applied to data. A blog post follows a structure. A social caption follows a voice. A schema update follows a format. Once you've approved that the template is right — once you've seen five blog posts that hit your tone, five captions that sound like you, five schema blocks that are accurate — you've validated the pattern. The sixth through five-hundredth outputs are not meaningfully riskier than the fifth.

The practical gate policy for marketing:

• Week 1: Run every output through the approval queue. Read each one. You're not approving content — you're validating that the template is calibrated.
• Week 2–3: If the pattern is consistent, widen the gate. Let the system post automatically and review in batch at end of week.
• Week 4+: Move to exception-based review. Flag outputs that deviate from expected patterns (length, sentiment, topic drift) for human review. Let the rest publish.

The cost of getting this wrong is low. A blog post that's slightly off-brand doesn't lose you a customer. It might lose you a click. That's a recoverable error.

The cost of being too cautious is high. If you're manually approving every social caption, every blog post, every schema update — you've just rebuilt the busywork you were trying to eliminate, with an extra click in the middle.

How Self-Driven Support gates should work

Support automation is where you should be moving slowest toward full autonomy — not because the AI can't handle it, but because the cost of a wrong output is asymmetrically higher.

Consider what's in a typical support queue:

• A customer asking why their order hasn't arrived (they're already worried)
• A one-star review mentioning a specific employee by name (it's public)
• A refund request for a product they say was damaged (it may be legitimate or fraudulent)
• A DM from someone who bought the wrong size and is embarrassed about it (they're vulnerable)

Each of these is a human in a heightened emotional state. The reply they get will either resolve the tension or amplify it. An automated reply that misreads the situation — that's too formal, too dismissive, too quick to deny, or too slow to empathize — can turn a recoverable complaint into a chargeback, a public callout, or a lost customer for life.

The practical gate policy for support:

• Phase 1 — Classify and draft, approve everything: Let the system triage and draft replies for every incoming message. You review and send. You're not doing less work yet — you're training yourself on what the AI gets right and wrong.
• Phase 2 — Approve by reply class: Once you've seen the AI nail a specific reply type consistently (e.g., order status updates, shipping delay acknowledgments), open the gate for that class only. Keep the gate closed for refunds, complaints, and reviews.
• Phase 3 — Widen selectively: Refund replies earn autonomy when the AI has correctly handled twenty refund conversations without a human correction. Review responses earn autonomy when your average star rating hasn't dropped after thirty auto-responses. You're granting autonomy based on track record, not trust.

The key insight: support autonomy is earned reply-class by reply-class, not granted platform-wide.

The same queue, different policies

One thing that confuses people when they first look at Koira's approval queue: it's a single inbox. Marketing outputs and support outputs both flow through it.

That's intentional. The interface is unified. But the policy you apply to what comes through it should be different by function.

Think of it like a restaurant pass — the same window where every dish comes through before it goes to the table. But a side salad gets waved through immediately. A dish with a known allergen on the table gets held for a verbal confirmation with the server. Same window, different rules per item type.

You configure this in practice by:

1. Tagging outputs by function so you can see at a glance whether something is a marketing output or a support output
2. Setting auto-approve rules for marketing output classes that have passed your calibration period
3. Keeping support outputs in manual review until specific reply classes have earned autonomy
4. Reviewing by exception in marketing, reviewing by default in support — until the track record says otherwise

Where the two functions actually overlap

There is one zone where marketing and support blur: public-facing reactive content.

Review responses live here. They're a support function (responding to a customer) but a marketing function (the response is public and shapes how prospects perceive you). A reply to a three-star review on Google is both.

For review responses, apply the support gate policy — not the marketing one. The fact that it's public makes the blast radius higher, not lower. A bad review response is seen by every future customer who reads that listing. Treat it like support until you have a strong track record.

Similarly, social DMs that come in through your business account are support, not marketing, even though they arrive through a marketing channel. The moment a message is addressed to a specific person, apply the support gate.

A practical example: the same wrong output, different consequences

Imagine Koira generates a slightly generic output — the kind of thing that's technically accurate but sounds a bit templated.

In marketing: That generic blog post intro gets published. A few readers bounce faster than usual. Your average session duration dips 4%. You notice it in your weekly review, tweak the prompt, and the next post is better. Total cost: one mediocre post.

In support: That generic reply goes to a customer who just told you their anniversary gift arrived broken. The reply acknowledges the issue and offers a 10% discount on their next order. The customer — who was already upset — now feels dismissed. They post the exchange on Instagram. Three of their followers screenshot it. One of them was about to place a $400 order with you. Total cost: one customer lost for life, one $400 order that never happened, one public callout.

Same quality of output. Completely different consequences.

The gate exists to absorb the cost of imperfection before it reaches the customer. In marketing, you can afford to let imperfect outputs through because the cost is low. In support, you can't — until you've proven the system doesn't produce imperfect outputs for that specific reply class.

How to configure your gates across both functions

Below is the step-by-step process for setting up gate policies when you're running both Self-Driven Marketing and Self-Driven Support on the same platform.

The underlying principle

Automation autonomy should be calibrated to the cost of a wrong output — not to the capability of the AI.

Koira's platform is capable of running both marketing and support at high autonomy. The question is never "can it?" — it's "what happens when it gets one wrong?" In marketing, you recover. In support, you may not.

Set your gates accordingly. Earn autonomy in support the same way you'd earn trust with a new hire: start with supervision, widen the scope as the track record builds, and never grant blanket trust before it's been demonstrated in the specific context that matters.

The platform is the same. The stakes are not.